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PREFACE 

Principles of Operation, The EPSILON System, Version 
1.0, was published on 15 June 1976 as an IBM Confiden¬ 
tial document. It was declassified to non-confiden- 
tial on 1 March 1978, with authorization to 
distribute copies to any interested party inside or 
out of IBM. 

This document is a reprint of the original without 
revision of content. Minor text changes have been 
made, however, in order to take advantage of format 
improvements possible with new text and printing fa¬ 
cilities. 




Version 1.0 
15 June 1976 


Preface 


15 October 1980 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


CONTENTS 


1.0 INTRODUCTION . 1 

Nature of EPSILON Systems 
Relation to System/360/370 
References 

2.0 BASIC CONCEPTS AND DEFINITIONS .. 4 


Processes 

Initiation and Termination 

Process Classes 

Storage 

Data Protection 
Instruction Sets 
Input/Output 
Addressing Conventions 
Instruction Execution 
Exceptions 

3.0 STORAGE AND SPACES . 13 

M-space Allocation 
B-space Allocation 
Pointers 
Space Retrieval 
Domain Identifier 
Changes of Custody 
Instruction Descriptions 
ALLOCATE SPACE 
FREE SPACE 
SAVE SPACE 
LOAD SPACE 
STORE POINTER 
LOAD POINTER 
TEST POINTER 

ASSIGN DOMAIN IDENTIFIER 
LOAD DOMAIN IDENTIFIER 
SET PROTECTION VECTOR 
INSERT PROTECTION VECTOR 

4.0 PROCESS DISPATCHING . 28 

Computation Cycles 

C-process Dispatching Overview 

Dispatching Condition 

Selection Routines 

C-process Dispatching Example 

R-process Dispatching 

Computation Cycle Overrun 

5.0 C-PROCESSES: GENERAL COMPUTATION . 37 

Queues 

Process Model Definition 
Process Model Deletion 


i i 




Table of Contents 


15 October 1980 








Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


Initiation 
State Vector 
Process Entry 
Linkage 

Communication via Queues 
Domain Idantication 
Shared Data 
Deadlock Avoidance 
Termination 
Exception Handling 
Forced Exceptions 
Instruction Descriptions 
DEFINE QUEUE 
QUEUE INDEX 

DEFINE C-PROCESS MODEL 
STORE CMDB 
DELETE QUEUE 
INITIATE PROCESS 

LOAD PROCESS INSTRUCTION COUNTER 

IDLE 

WAIT 

CALL 

RETURN 

ENQUEUE 

DEQUEUE 

QUEUE SWITCH 

QUEUE WAIT 

CLOSE GATE 

OPEN GATE 

EXIT 

TERMINATE PROCESS 
DEFINE EXCEPTION MODULE 
SET EXCEPTION MASK 
SET BREAKPOINT MASK 
FORCE PROCESS EXCEPTION 

6.0 R-PROCESSES: EVENT RESPONSE . 71 

Process Sources 
Process Model Connection 
Initiation 

Process Communication 
Deadlock Detection 
Termination 
Exception Handling 
Instruction Descriptions 
STORE SOURCE LIST 
CONNECT R-PROCESS MODEL 
CONNECT R-PROCESS MODEL INDIRECT 
STORE SOURCE STATUS 
SIGNAL SOURCE 

7.0 D-PRQCESSES: INPUT/OUTPUT . S5 

I/O devices 


Table of Contents 


15 October 1980 





Principles of Operation 
The EP.SILON System 


Version 1.0 
15 June 1976 


Process Model Connection 
I/O Requests 
D-Process Environment 
Dispatching 

I/O Request Processing 
Input/Output Operations 
I/O Request Disposition 
Use of Domain Identifier 
Termination 
Exception Handling 
Attachment Interfaces 
Instruction Descriptions 
STORE DEVICE LIST 
STORE DEVICE DESCRIPTION 
CONNECT D-PROCESS MODEL 
CONNECT D-PROCESS MODEL INDIRECT 
STORE DEVICE STATUS 
REQUEST INPUT/OUTPUT 
TEST INPUT/OUTPUT 
NEXT REQUEST 
START DEVICE 
WAIT DEVICE 
HALT DEVICE 
SET DEVICE STATUS 
END I/O REQUEST 
RESERVE DEVICE 
END PROCESS 

3.0 GENERAL INSTRUCTIONS . 116 

Fixed-Point Arithmetic 
ADD 

ADD HALFWORD 
ADD LOGICAL 
COMPARE 

COMPARE HALFWORD 
COMPARE LOGICAL 
DIVIDE 
LOAD 

LOAD AND TEST 
LOAD COMPLEMENT 
LOAD HALFWORD 
LOAD MULTIPLE 
LOAD NEGATIVE 
LOAD POSITIVE 
MULTIPLY 

MULTIPLY HALFWORD 

SHIFT LEFT DOUBLE 

SHIFT LEFT DOUBLE LOGICAL 

SHIFT LEFT SINGLE 

SHIFT LEFT SINGLE LOGICAL 

SHIFT RIGHT DOUBLE 

SHIFT RIGHT DOUBLE LOGICAL 

SHIFT RIGHT SINGLE 


Table of Contents 


v 


15 October 1980 




Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


SHIFT RIGHT SINGLE LOGICAL 
STORE 

STORE HALFWORD 
STORE MULTIPLE 
SUBTRACT 

SUBTRACT HALFWORD 
SUBTRACT LOGICAL 
Logical Operations 
AND 

COMPARE LOGICAL 

COMPARE LOGICAL CHARACTERS UNDER MASK 

EXCLUSIVE OR 

INSERT CHARACTER 

INSERT CHARACTERS UNDER MASK 

MOVE 

OR 

STORE CHARACTER 

STORE CHARACTERS UNDER MASK 

TEST AND SET 

TEST UNDER MASK 

TRANSLATE 

TRANSLATE AND TEST 
Branching 

BRANCH AND LINK 
BRANCH ON CONDITION 
BRANCH ON COUNT 
BRANCH ON INDEX HIGH 
EXECUTE 
LOAD ADDRESS 
Long Operands 

COMPARE LOGICAL LONG 
MOVE LONG 
TRANSLATE 

TRANSLATE AND TEST 
Decimal Feature 
ADD DECIMAL 
COMPARE DECIMAL 
CONVERT TO BINARY 
CONVERT TO DECIMAL 
DIVIDE DECIMAL 
EDIT 

EDIT AND MARK 
MOVE NUMERICS 
MOVE WITH OFFSET 
MOVE ZONES 
MULTIPLY DECIMAL 
PACK 

SHIFT AND ROUND DECIMAL 
SUBTRACT DECIMAL 
UNPACK 

ZERO AND ADD 
Floating-Point Features 
ADD NORMALIZED 


v 1 


Table of Contents 


15 October 1980 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


ADD UNNORMALIZED 

COMPARE 

DIVIDE 

HALVE 

LOAD 

LOAD AND TEST 
LOAD COMPLEMENT 
LOAD NEGATIVE 
LOAD POSITIVE 
LOAD ROUNDED 
MULTIPLY 
STORE 

SU3TRACT NORMALIZED 
SUBTRACT UNNORMALIZED 

9.0 SERVICE PROCESSES . 128 

The System Clock 
Time Events 
System Exceptions 
System Overrun 
Invalid Process Model 
Forced Exception 
Statistics Collection 
Domain End 

Instruction Descriptions 
REQUEST TIME EVENT 
STORE CLOCK 

FORCE SYSTEM EXCEPTION 

10.0 SYSTEM INQUIRY FACILITIES ... 139 

Configuration Data 
Current State Data 
Collection of Statistics 
Assignment of Counters 
Statistics Records 
Domain Statistics 
Software Statistics 
Process Monitoring 
Instruction Descriptions 

STORE CONFIGURATION DATA 
STORE PROCESS MODEL LIST 
STORE DOMAIN LIST 
STORE COMPUTATION CYCLE RECORD 
COLLECT STATISTICS 
. SET COLLECTION MASK 

DEFINE STATISTICAL COUNTER GROUP 
ACQUIRE STATISTICAL COUNTER GROUP 
SET MONITOR CONDITIONS 
SET MONITOR MASKS 

11.0 MALFUNCTION DETECTION AND RECOVERY . 173 

Hardware Malfunction 
Invalid System Data 


Table of Contents 


VI 1 


15 October 1980 






Principles of Operation 
' The EPSILON System 


Version 1.0 
15 June 1976 


System Operation Error 
Error Signal Mask 
Error Signal Processes 
Instruction Descriptions 
SET ERROR MASK 
DIAGNOSE 

12.0 SYSTEM INITIALIZATION . 180 

Overview 

Initialization Data Table 
System Parameters 
Dispatching Structure 
Space Definition 
Service Process Models 
Regular Process Models 
System Checkpoint 
Application Initialization 
System Termination 
Instruction Descriptions 
CHECKPOINT 


Table of Contents 


15 October 1980 




Principles of Operation 
The EPSILON System 


Versi on 1.0 
15 June 1976 


1.0 INTRODUCTION 

EPSILON is a computer system archi¬ 
tecture which is an evolution of Sys- 
tem/360 architecture into new 
control and addressing capability, 
leaving the basic computational 
capability unchanged. The primary 
objective is to provide a family of 
computer systems consistent with the 
installed S/360 base, that can be op¬ 
erated efficiently over a large set 
of configurations. hierarchically 
distributed or not, and over a sub¬ 
stantially wider range of applica¬ 
tions than current systems. 

1.1 Nature of EPSILON systems 

In EPSILON systems many of the func¬ 
tions provided in other computer sys¬ 
tems by supervisory control programs 
have been included in the basic in¬ 
struction set, not only as a means of 
improving software performance but 
also as a way of promoting more uni¬ 
formity in programming and operating 
systems. These supervisory func¬ 
tions, together with the facilities 
that support them, incorporate con¬ 
cepts and views of the computing 
environment which are sometimes ex¬ 
hibited explicitly, and are always 
inherent in the assumptions underly¬ 
ing the semantics of the instruc¬ 
tions. The character and appearance 
of EPSILON systems is dominated by 
these concepts. 

o Multiprocessing is assumed to be 
the rule rather than the excep¬ 
tion, so that multiple concui— 
rent processes are the expected 
norm. In order to provide a sim¬ 
ple and stable programming envi¬ 
ronment in the face of the 
multitude of possibilities for 
processor interconnection and 
signalling, EPSILON systems ex¬ 
plicitly recognize processes as 
the basic unit of organized in¬ 
struction execution activity. 


and undertake to relieve soft¬ 
ware of dependency on physical 
processing mechanisms. Conse¬ 
quently, system microcode man¬ 
ages all activity connected with 
assignment of processors to pro¬ 
cesses, and the instruction exe¬ 
cution behavior of an EPSILON 
system is independent of the num¬ 
ber of processing mechanisms it 
contains. 

o Two kinds of time constraints are 
subsumed as an integral part of 
the computing environment 1 

any event (signal) must be 
acted upon within some maxi¬ 
mum time following its oc¬ 
currence 

any computation must be com¬ 
pleted within a time inter¬ 
val determined by when the 
output of the computation is 
to be used. 

Because the time of occurrence of 
an event is unpredictable, event 
response constraints are in bas¬ 
ic conflict with orderly compu¬ 
tation, as they may require 
pre-emption of allocated re¬ 
sources. As an aid to the resol¬ 
ution of this conflict, 
processes in EPSILON systems are 
separated into three classes, 
each of which is provided facili¬ 
ties designed to match a partic¬ 
ular kind of activity. One class 
is for general computation and 
two are for event response, one 
of those being for input/output. 
The system resolves basic re¬ 
source conflicts between indi¬ 
vidual processes, and between 
process classes, using informa¬ 
tion supplied as part of on-going 
process activity. 
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o The general division of function 
between the system and individ¬ 
ual processes is based on previ¬ 
ous software experience, but the 
specific activity undertaken by 
the system is conditioned by a 
system view of the process class 
involved. Thus, process dis¬ 
patching and storage allocation 
are functions of the system be¬ 
cause experience has shown that 
they occur in nearly all general 
purpose supervisory software. 
However, dispatching of computa¬ 
tional processes is time-driven, 
based on viewing those processes 
as data transformations, while 
dispatching of response class 
processes is event-driven. 

Similarly, storage is addressed 
only in segments (spaces) pro¬ 
vided by the system in response 
to allocation instructions. Two 
levels of storage exist, one for 
data and instructions being pro¬ 
cessed, the other for permanent 
residence. Response class pro¬ 
cesses have only limited access 
to data in permanent storage, and 
none to instructions. Computa¬ 
tional processes, however, are 
provided with automatic loading 
facilities that allow them to 
reference permanent storage di¬ 
rectly in linkage instructions. 

o The separation of process by 
class of activity leads to a na¬ 
tural separation of instructions 
by execution validity with re¬ 
spect to class, and to modal in¬ 
terpretation of instructions. 
An instruction may be executable 
only within a process of a given 
class, or may be common to two or 
more classes. Instructions com¬ 
mon to more than one class may 
have the same interpretation for 
each class, or may have an inter¬ 
pretation which varies by class 
in order to be consistent with 
the presumed nature of the pro¬ 


cesses. 

EPSILON systems therefore can be 
thought of as having three separate 
instruction sets, each of which pre¬ 
sents programmers with a set of fa¬ 
cilities designed to promote a 
particular class of activity. The 
instruction sets are independent in 
the sense that every process in the 
system consists of interpretat i on 
and execution of instructions se¬ 
lected from exactly one of the sets; 
they are connected in the sense that 
at least one instruction of each set 
can cause initiation of a process for 
some other set. The overall effect 
is one of interdependence, not be¬ 
cause the instructions have the same 
formats (which is an accident of 
choice), but because every applica¬ 
tion is carried out by a mixture of 
processes from all three classes. 

1.2 Relation to Svstem/360/370 

EPSILON data types are the same as 
those of System/370, have the same 
formats, and are subject to the same 
positioning rules with respect to 
half-word, word, and double-word 
boundaries. EPSILON instructions 
have formats identical to those of 
S/360 instructions, and where an in¬ 
struction is common to EPSILON and 
S/360 the operation code is the same. 

The EPSILON instruction list in¬ 
cludes all non-privileged S/360 
instructions, and all non-privileged 
instructions of S/370 with the excep¬ 
tion of a few whose function is per¬ 
formed in some other way. 
Instruction interpretation is de¬ 
fined so that instructions executed 
within a single space of an EPSILON 
system, which refer only to data 
within that space, behave as they 
would when executed within a 360 or 
370 system. Consequently, all S/360 
and most S/370 programs which use on¬ 
ly non-privileged instructions can 
execute without change on EPSILON 
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system models, and will obtain the 
same results as on S/360 or S/370 
models. 

The privileged instructions, the 
control registers, dynamic address 
translation, and other visible con¬ 
trol mechanisms of S/360 and S/370 do 
not appear in EPSILON systems, as the 
EPSILON architecture extends S/360 
in a direction for which such mech¬ 
anisms are inappropriate. Furthei— 
more, the input/output system, while 
similar to S/360 and S/370 at the de¬ 
vice command interface, operates 
within a disciplinary framework not 
required on those systems. 

A microcode feature is available 
which will provide for interpreta¬ 
tion of S/360 privileged instruc¬ 
tions. A similar feature is 
separately available for S/370. 
These features each provide a basic 
mechanism by which any S/360 or S/370 
program can execute within a single 
space of an EPSILON system, but it is 
expected that software will provide 
the additional functions required 
for correct interpretation of the 
program within its programming sys¬ 
tem environment. 


1.3 References 

This document- is intended as a 
self-contained principles of opei— 
ation. However, to avoid duplication 
of much that is well-known, the read¬ 
er is assumed to have a basic know¬ 
ledge of S/360, and some material is 
included by reference to S/360 and 
S/370 principles of operation: 

o POP360 indicates a reference to 
SRL document GA22-6281-8, IBM 
System/360 Principles of Opei— 
ation, ninth edition, November 
1970 

o POP370 indicates a reference to 
SRL document GA22-7000-3, IBM 
System/370 Principles of Opei— 
ation, fourth edition, January 
1973. 

References are enclosed in square 
brackets when they are ancillary to 
the text, but are not enclosed when 
they supply the text. External ref¬ 
erences include a colon and page num¬ 
ber, other references do not. Thus, 
CPOP360 ; 41] refers to page 41 of the 
S/360 principles of operation, and 
[Section 4.3] refers to Section 4.3 
of this document. 
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2.0 BASIC CONCEPTS AND DEFINITIONS 

The following paragraphs describe 
some of the basic system concepts and 
introduce definitions which will be 
used throughout the remainder of the 
document. The defined terms, includ¬ 
ing ordinary words used in a special 
technical sense, appear in bold type 
at their first appearance. If a term 
can have values, the first appearance 
of the name of a value is either 
under 1ined or exhibited on a separate 
di splay line. 

2.1 Processes 

All instruction execution in an 
EPSILON system must occur as part of 
an organized activity called a pro¬ 
cess. A process consists of a suc¬ 
cession of states, each of which is 
described by the data contained in a 
State vector. Transition from a given 
state to its successor state is ac¬ 
complished by action of some process¬ 
ing mechan i sm , which 

o selects an instruction from the 
sequence of instructions cui— 
rently associated with the pro¬ 
cess 

o interprets the instruction in 
the context of the state vector 
data, and carries out the func¬ 
tion of the interpreted instruc- 
t i on 

o alters the state vector data (if 
necessary) to reflect the result 
of execution of the instruction. 

The number of processes active in the 
system at any time is arbitrary, lim¬ 
ited only by availability of physical 
resources. The number of processing 
mechanisms in the system is not a 
factor which limits the number of 
processes; in fact, the functional 
(i.e. instruction execution) behav¬ 
ior of the system is not affected by 


the number of processing mechanisms, 
though the system throughput or re¬ 
sponse to events may well be af¬ 
fected . 

2.2 Initiation and Termination 

Process initiation is the activity of 
bringing a process into being and 
setting up its initial state. Initi¬ 
ation can occur only as the result of 
activating a process source, and is 
carried out as a closed function of 
the system. Some process sources are 
specifiable as part of the system and 
are factory or field installed, oth¬ 
ers are generated as a result of in¬ 
struction execution. The following 
kinds of process sources occur or may 
occur in any EPSILON system. 

o Input/Output Devices. A source 

is installed at the factory or in 
the field for every I/O device 
port attached to a system. An 
I/O device source is activated 
whenever an associated device 
signals a device event (e.g. 
attention). I/O device sources 
can also be activated by the RE¬ 
QUEST INPUT/OUTPUT instruction. 

o External Signal Interface. An 

external signal interface can be 
factory or field installed in any 
EPSILON system. A source is 
installed for each signal line, 
and is activated when the appro¬ 
priate signal appears on the 
line. 

o Queues. Queues can be specified 

to act as process sources. The 
source is activated whenever an 
item is placed into the queue and 
the queue was empty at the time. 

Activation of a process source always 
results in a request for process ini¬ 
tiation. The request may not result 
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in the actual initiation of a pro¬ 
cess, however, if a process already 
exists which meets the request spec¬ 
ifications. 

Process termination is the activity 
of delating a process from the sys¬ 
tem; it is the inverse of process in¬ 
itiation, and is also carried out as 
a closed function of the system. 
Termination can occur only as the re¬ 
sult of execution of a termination 
request instruction, either by the 
process to be terminated or by a pro¬ 
cess detecting a requirement for tei— 
mination. 

2.3 Process classes 

In order for process initiation to 
operate as a closed function, it is 
necessary to provide the system with 
data which describes the structure 
and content of the initial state vec¬ 
tor. Such a collection of data is 
called a process modal, and a process 
derived from a given model is called 
an instance of that model. All pro¬ 
cesses are instances of some process 
model. 

There are three classes of process 
model, each giving rise to a corre¬ 
sponding class of process. The 
classes are designated as the C-pro- 
ccss class, the R-process class, and 
the D-pr0C2S5 class. The capital 
letters used to distinguish these 
process classes will also be used to 
distinguish items and charactei— 
istics unique to the classes. Thus, 
'D-process model' will be used to re¬ 
fer specifically to a process model 
giving rise to a process of the 
D-process class, while 'process mod¬ 
el* will be used if the reference is 
to apply to any process model. 

Each of the three classes of process 
is designed to provide facilities 
which are matched to a particular 
class of activity ■ 


o C-processes for general computa¬ 
tion 

o R-processes for response to ex¬ 
ternal or internal event signals 

o D-processes for I/O device con¬ 
trol and data transfer. 

However, any process can carry out 
any kind of activity as long as it 
has access to the instructions and 
data required for that activity. 

The separation of process models and 
processes into classes is achieved by 
adoption of rules and procedures 
which regulate the general character 
of their behavior. Aspects regulated 
include = 

o Initiation. Process sources are 

restricted to association with 
specific classes. I/O device 
sources, for example, can cause 
initiation of D-processes or 
R-processes, but not C-pro¬ 
cesses, while queues can only 
cause initiation of C-processes. 

o Instruction set. The classes 

differ in the states allowed 
their processes. Consequently, 

the structure and content of 
the associated state vectors 
is not the same from class to 
class 

the instructions which can 
be executed vary by class. 

A given processing mechanism is 
therefore not necessarily as¬ 
signable to more than one class. 

o Process management. The process 

dispatching rules, the amount 
and type of dispatching control, 
and the communication and data 
sharing mechanisms made avail¬ 
able to processes, distinguish 
the process management functions 
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of one class from those of anoth¬ 
er . 

The rules and procedures governing 
behavior of processes appear in Chap¬ 
ters 5, 6, and 7, which discuss the 
specific characteristics of each 
process class. 

2.4 Storage 

Main storage in an EPSILON system 
consists of two collections of data 
bytes, called M-storags and B-Stor- 
aga. M-storage has predictable ac¬ 
cess time, and may be volatile; 
B-storage has unpredictable access 
time, and is non-volatile. Data and 
instructions may occupy B-storage 
for permanent residence, but must re¬ 
side in M-storage before they can be 
processed. 

Initially, both types of storage con¬ 
sist of a pool of 8-bit bytes which 
are unrelated and not addressable. 
The total number of bytes of storage 
and the number of bytes in each pool 
is installed at the factory, but ad¬ 
ditional bytes may be field in¬ 
stalled. Addressability is obtained 
by executing an allocation instruc¬ 
tion, which defines a unit of stoi— 
age, either an M-spaca or a B-spaca, 
consisting of a specified number of 
bytes withdrawn from the M-storage or 
B-storage pool. 

o Both M-spaces and B-spaces are 
referenced by use of a 32-bit 
identifier, called a pointer, 
unique to the space. The pointer 
for a space is assigned by the 
system when the space is allo¬ 
cated. Pointer values are not 
predictable, except for the null 
pointer which is always a zero 
field. 

o Bytes within a B-space are not 
individually addressable, though 
they are considered to be se¬ 
quenced contiguously, starting 


with sequence number 0. 

o Bytes within an M-space are ad¬ 
dressable, with address loca¬ 
tions corresponding to sequence 
numbers. A 24-bit address is ap¬ 
plied relative to location 0 to 
reference any desired byte. Ad¬ 
dressing therefore accommodates 
M-spaces up to 16,777,216 bytes 
in extent. 

A space remains in existence until a 
FREE SPACE instruction referring to 
it is successfully executed, at which 
time it is deleted from the system 
and the M-storage or B-storage pool 
enlarged by the number of bytes in 
the M-space or B-space. The total 
number of spaces in existence at any 
one time is constrained only by the 
requirement that the sum of all 
M-spaca extents not exceed the total 
number of M-storage bytes installed 
in the system, and the sum of all 
B-space extents not exceed the total 
number of B-storage bytes installed. 

Information can be moved between 
M-storage and B-storage by executing 

o a LOAD SPACE instruction, which 
copies the contents of a B-space 
into an M-space in byte sequence 
order 

o a SAVE SPACE instruction, which 
copies an M-space into a B-space. 

However, there are no instructions 
which will alter the division of 
bytes between M-storage and B-stoi— 
age. 

2.5 Data Protection 

In order to provide a basic framework 
for protection of data, every space 
is assigned to the custody of some 
process or group of processes, and 
allocated read and write access. Cus¬ 
tody identifies the group of pro¬ 
cesses that can delete the space or 
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change its access. There are three 
types of custody. 

o Private. The space can be deleted 
or have its access type altered 
only by one specific process. 

o . Family. All processes which are 
instances of a given process mod¬ 
el are said to be members of that 
process model, family. Family 
custody allows any member of the 
family to delete the space or al¬ 
ter its access type. 

o Bound. The space is bound to some 
process model, or to the system. 
It cannot have its access type 
altered, and can be deleted only 
when the process modal is de¬ 
leted, or the system is initial- 
i zed. 

Custody is transferred by the execu¬ 
tion of certain instructions. For 
example, when an ENQUEUE instruction 
is completed, the space is removed 
from its current custody and becomes 
part of the queue. It is subsequent¬ 
ly assigned to the custody of the 
process which dequeues it. 

The read access of a space identifies 
the group of processes that can read 
data from the space, and the write 
access those that can store data into 
it. In decreasing order of restric¬ 
tion, the types of access are 

o Private = access restricted to a 

single process 

o FamiIv = access restricted to 

members of a particular family 

o Domain : access restricted to 

processes acting on behalf of 
some specified data domain 
CSection 3.5] 

o Public : access allowed to any 

process. 


The protection vector of a space is 
the triple of the values of custody, 
read access, and write access. 
M-spaces can have any legitimate pro¬ 
tection vector value. B-spaces, how¬ 
ever, cannot be assigned private 
custody or private read access. 
These restrictions are automatically 
applied by the instructions which act 
on B-spaces. 

2.6 Instruction Sets 

Processing mechanisms are either 
internal to an EPSILON system or are 
devices attached externally by means 
of the I/O attachment interfaces. 
I/O devices (or device adapters) exe¬ 
cute instructions which are special¬ 
ized to their particular control and 
data transfer characteristics. They 
execute such instructions as part of 
a D-process, being assigned as the 
associated processing mechanism on 
execution of the START DEVICE in- 
struction. 

In contrast to these external device 
instruction sets, all internal 
EPSILON instructions conform to spe¬ 
cific formats and prescribed intei— 
pretation conventions. They are 
classified by execution validity 
with respect to process class, and by 
mode of interpretation. 

o Some instructions are executable 
within a process of any process 
class, some are common to two of 
the process classes, some are 
valid only within one of the 
classes. 

o The instructions valid within 
R-processes are called the basic 
instruction set, those valid 
within C-processes are called 
the computational instruction 
set, and those valid within 
D-processes are called the 
peripheral instruction sat. A 
decimal feature and a floating¬ 
point feature may be independ- 


Chapter 2 


7 


Basic Concepts 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


ently added to the standard 
computational instruction set. 

o Instructions common to more than 

one process class may have a 
fixed interpretation, or may be 
modal instructions whose intei— 
pretation varies with class. 
Modal instructions allow subrou¬ 
tines to be written which auto¬ 
matically conform to the 
differing interpretation con¬ 
ventions of the process class 
within which they are executed. 

Internal processing mechanisms are 
of two types with respect to the in¬ 
struction set classification. 

o A central processing unit (CPU) 

can execute the basic instruc¬ 
tion set or the computational in¬ 
struction set, or both. 

o A peripheral processing unit 

(PPU) can execute the peripheral 
instruction set. 

Thera must be at least one CPU and 
one PPU in every EPSILON system. If 
there is only one CPU it must have 
both the basic instruction set and 
the standard computational instruc¬ 
tion set installed; if there is more 
than one CPU, then the division be¬ 
tween basic and computational 
instruction capability is arbitrary, 
as long as each capability is 
installed. Some models, however, may 
offer only limited combinations of 
CPU capability. The <decimal and 
floating-point features can be 
installed only in a CPU in which the 
computational instruction set has 
been installed. 

2.7 Input/Output 

An input/output operation transfers 
data between an M-space and an I/O 
device. The transfer mechanism is 
provided by the peripheral process¬ 
ing units of the system, each of 


which actually consists of two parts: 

o an I/O attachment interface, 
which supplies logical and elec¬ 
trical connection between 

M-storage and I/O devices or de¬ 
vice adapters 

o a processing mechanism for in¬ 
terpretation and execution of 
the instructions by which D-pro- 
cesses control transmission of 
data between M-spaces and I/O de- 
vices. 

The attachment interface of a PPU is 
either a DC interlocked interface, 
called a channel, or a serial, 
clocked, bit-frame transmission 
interface, called a loop. The pro¬ 
cessing mechanism of a PPU interprets 
instructions and data the same way in 
either case, so that processes are 
not affected by the form of attach¬ 
ment chosen for any I/O device. 

2.8 Addressing Conventions 

The EPSILON instructions have the 
same structure and the five basic 
formats of S/360 instructions: RR, 
RX, RS, SI, and SS [POP360:12,13]. 
There are, however, significant dif¬ 
ferences of interpretation of the 
fields referenced in the instruc¬ 
tions: 

o register references designate 
special data private to a process 

o storage addresses are generated 
by rules which cause reference to 
a location in some allocated 
space. 

The state vector of every process 
contains sixteen 8-byte fields, 
called general registers, which are 
referenced by the R, X, and B fields 
of any instruction executed within 
the process. The state vector of ev¬ 
ery C-process also contains four ad¬ 
ditional 8-byte fields, called 
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floating-point registers, which are 
referenced by the R field of float¬ 
ing-point instructions executed 
within the process. 

The eight bytes of a general register 
are divided into two independent 
4-byte fields. The first field, 
called an arithmetic register, 
always contains a binary number used 
either for arithmetic calculation or 
to compute locations relative to the 
origin of some allocated space. The 
second field, called a pointer regi¬ 
ster, can contain only a pointer to 
an M-space or B-space, or the null 
pointer, and is used only for address 
generation. 

In the RR, RX, and RS instruction 
formats, the R field may designate 
the arithmetic register, the pointer 
register, or the complete general 
register. In the RX instruction foi— 
mat, the X field designates the 
arithmetic register, treated as a 
24-bit index. In the RX, SI, and SS 
instruction formats, the B field des¬ 
ignates the complete general regi¬ 
ster, whose arithmetic and pointer 
fields combine to form the base for 
an operand address. Address genei— 
ation is carried out as follows. 

o The contents of the pointer regi¬ 
ster designated by the B field 
identifies the space being 
addressed. An access exception 
[Section 2.10] will occur if the 
register does not contain a 
pointer to an allocated M-space 
or B-space. 

o The low order 24 bits of the con¬ 
tents of the arithmetic register 
designated by the B field are 
treated as an unsigned binary in¬ 
teger specifying the bass ad¬ 
dress relative to the identified 
space. 

o The low order 24 bits of the con¬ 
tents of the arithmetic register 


designated by the X field (in RX 
format instructions) are treated 
as an unsigned binary integer 
index relative to the base ad¬ 
dress. 

o The 12-bit number contained in 

the D field of the instruction is 
treated as an unsigned binary in¬ 
teger displacement relative to 
the base address. 

o The full address is calculated by 

adding the base address, index, 
and displacement as 24-bit bina¬ 
ry numbers, ignoring overflow, 
to form a 24-bit location value. 
This value designates the byte in 
the identified space whose se¬ 
quence number is equal to the lo¬ 
cation value. 

In forming addresses, a special in¬ 
terpretation is given to zeros in the 
X and B fields, and to the null 
pointer. A zero in the X field indi¬ 
cates the absence of indexing, and a 
zero will be used for the index value 
irrespective of the contents of 
arithmetic register zero. A zero in 
the B field is treated in the same 
way if the address being generated is 
actually a location relative to an 
implied space, as in the LOAD 
ADDRESS, EXECUTE, and branching in¬ 
structions [Section 8.3]. No special 
treatment is applied to a B field of 
zero when the space must be explicit¬ 
ly identified, as is the case with 
most instructions. 

The null pointer is interpreted as 
referring to a special null space 
which has public read and write ac¬ 
cess, and is zero bytes in extent. 
An address always lies outside the 
null space, so that an addressing ex¬ 
ception will occur if the address is 
generated in connection with any 
instruction which refers to a loca¬ 
tion in the space. 
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2.9 instruction Execution 

When a processing mechanism is as¬ 
signed to a process, it fetches 
instructions from the M-space loca¬ 
tion designated by the process in¬ 
struction counter contained in the 
state vector of the process. The in¬ 
struction address is then increased 
by the number of bytes in the in¬ 
struction in order to address the 
next instruction, except that in the 
case of branching, linkage, and loop 
control instructions, the next in¬ 
struction address is calculated as 
part of the instruction execution it¬ 
self . 

In concept, the processing mechanism 
fetches and executes instructions 
one at a time, with the results of 
the execution of one instruction 
available preceding the execution of 
the next instruction. In practice, 
instructions may be fetched out of 
order or executed in a sequence phys¬ 
ically different from the conceptual 
one, in order to take advantage of 
overlap of instruction fetch with op¬ 
erand access. However, the results 
generated for any instruction are 
those that would have been generated 
if the conceptual sequence had been 
followed, as a processing mechanism 
will not be switched from one process 
to another without first having 
brought physical and conceptual exe¬ 
cution into agreement. 

These actions also provide assurance 
that data private to a process will 
appear to behave exactly as expected 
by the conceptual execution se¬ 
quence. In the normal course of 
events, however, there is no such im¬ 
plicit assurance that data accessi¬ 
ble to more than one process will 
appear to behave with such integrity, 
as all processes in an EPSILON system 
can be advancing concurrently. This 
occurs not only because there genei— 
ally are multiple CPU and PPU, but 
also because any particular process¬ 


ing mechanism may be switched from 
one process to another between any 
two instuctions. Consequently, the 
instructions CLOSE GATE and OPEN GATE 
provide controlled access to shared 
data, for use when the logic of a 
process requires that an instruction 
sequence have exclusive use of the 
data for some period of time [Section 
5.101. 

2.10 Exceptions 

When an instruction is completed, a 
2-bit condition code field in the 
state vector of the process may be 
set to a value which indicates an at¬ 
tribute of the result. For example, 
the condition code is set to the val¬ 
ue 1 for a fixed-point addition with 
a negative result, and to a 2 for a 
positive result. The condition code 
is inspected by the BRANCH ON CONDI¬ 
TION instruction, which then uses the 
value of the code to select the next 
instruction address. 

If a condition is encountered during 
instruction execution which pre¬ 
cludes the expected result, it may be 
indicated in the condition code, or a 
process exception may be raised. In 
general, the condition code is used 
to indicate unusual conditions not 
under control of the process within 
which the instruction is being exe¬ 
cuted (e.g. the 'storage not avail¬ 
able’ condition for ALLOCATE), while 
an exception signals a condition for 
which the process itself is responsi¬ 
ble. 

There are six exceptions which can 
occur for improper specification or 
use of an instruction, one which can 
be forced, and two which arise from 
fixed-point arithmetic. These 

exceptions, and their significance, 
are as follows. 

o Qperation = Either the operation 
code of the instruction is not 
assigned, the instruction is not 
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installed, or the instruction 
cannot be executed within the 
process because of process class 
execution restrictions 

o Execute ; An EXECUTE instruction 

is the subject of an EXECUTE in¬ 
struct i on 

o Access = Either a storage refei— 

ence is invalid because the 
pointer does not identify an al¬ 
located space, or the space has 
access for the instruction not 
allowed to the process 

o Addressing = A generated address 

lies outside the extent of the 
referenced space, or the space is 
currently not available for ad¬ 
dressi ng 

o Specification ■ An operand of the 

instruction does not meet some 
requirement restricting its lo¬ 
cation, reference identifier, or 
length 

o Data = An operand of the instruc¬ 

tion does not meet some require¬ 
ment on its structure or value 

o Forced • Occurs as the result of 

executing a FORCE PROCESS EXCEP¬ 
TION instruction, or when a pro¬ 
cess trace record is stored 

o Fixed-point overflow - A high-or¬ 

der carry has occurred or high- 
order significant bits have been 
lost as a result of executing a 
fixed-point add, subtract, 

shift, or sign-control instruc- 
ti on 

o Fixed-point divide : Either 

fixed-point division by zero has 
been attempted, the quotient ex¬ 
ceeds the register size, or the 
result of a CONVERT TO BINARY in¬ 
struction exceeds 31 bits. 

In addition, the following excep- 
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tions can occur when the decimal and 
floating-point features are in¬ 
stalled. 

o Decimal overflow ^ The destina¬ 
tion field of a decimal instruc¬ 
tion is too small to contain the 
result 

o Decimal divide : The quotient of 

a decimal instruction exceeds 
the size of the specified data 
f i eld 

o Exponent overflow : The result of 
a floating-point add, subtract, 
multiply, or divide instruction 
has a non-zero fraction and a 
characteristic greater than 127 

o Exponent underflow : The result 

of a floating-point add, sub¬ 
tract, multiply, divide, or 
halve instruction has a non-zero 
fraction and a negative charac¬ 
ter i st i c 

o Sianificance : The result of a 

floating-point addition or sub¬ 
traction has a zero fraction 

o Floating-point divide = A float¬ 

ing-point division by zero has 
been attempted. 

An 8-bit field in the state vector, 
called the exception mask field, de¬ 
termines the treatment of the eight 
arithmetic exceptions. Each bit of 
the mask corresponds to one of the 
exceptions; if the bit is 0, the ex¬ 
ception will be ignored if raised, if 
the bit is 1 the exception will be 
signalled to the process. The other 
exceptions cannot be masked, so are 
always signalled to the process. The 
methods of signalling exceptions 
vary by process class, as do the fa¬ 
cilities for acting in response to 
them. Details of exception proce¬ 
dures appear in Chapters 5, 6, and 7. 

Unusual conditions can also arise 
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which are not directly relatable to 
execution of a particular instruc¬ 
tion. Dispatching, for example, de¬ 
tects a possible CPU overload as a 
result of trying to meet the CPU re¬ 
quirements of all processes [Section 
4.73. Conditions of this kind for 
which remedial action is possible 
raise a system exception, and cause 


an exception process to be initiated. 
Exception process models are 
built-in to the system, but are pei— 
sonalized to individual systems by 
data supplied at system initializa¬ 
tion. Details of system exceptions 
and system exception procedures ap¬ 
pear in Chapter 9. 
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3.0 STORAGE AMD SPACES 

In any EPSILON system, storage is 
withdrawn from the storage pools to 
contain data and data structures used 
for system management. Part of the 
storage is withdrawn at system 
initialization [Chapter 12], while 
the remainder is withdrawn as the re¬ 
sult of conditions which occur during 
system operation (e.g. storage is re¬ 
quired for state vector data for a 
newly initiated process). Once with¬ 
drawn, such storage is not returned 
to the storage pools, but is retained 
and managed separately by the system 
microcode. 

The amount of storage used by the 
system thus grows with demand, but 
the demand falls off sharply as the 
data structures adjust in size to the 
operational load. After a relatively 
short initial period, the demand for 
additional system storage will occur 
only during periods of extraordinary 
use. These periods will themselves 
occur with decreasing frequency, so 
that eventually the division between 
system storage and storage available 
for space allocation remains con¬ 
stant. The value of this 
steady-state constant cannot be pre¬ 
dicted with certainty, but it is pos¬ 
sible to determine an approximate 
value from system initialization da¬ 
ta . 

Once the steady state has been 
reached, the execution time of all 
instructions which involve direct or 
indirect storage allocation falls 
within the bounds prescribed in the 
functional specifications of the in¬ 
dividual EPSILON systems. 

3.1 H-soaca Allocation 

The ALLOCATE SPACE instruction 
(ALLOC) provides for direct allo¬ 
cation of two kinds of M-spaces : 


o ordinary M-spaces are assumed to 
be intended to hold data but not 
instructions to be executed; 
such spaces cannot be the object 
of a linkage instruction 

o module M-spacas are assumed to be 
intended to hold instructions to 
be executed. A module space can 
be addressed to store and fetch 
data, but cannot be enqueued or 
transferred outside the custody 
of the original process family, 
except to bound custody; it can 
be made available to other pro¬ 
cesses as the object of a linkage 
instruction. 

The attribute of being a module or 
ordinary space is permanently re¬ 
tained by an M-space, and is inhei— 
ited by any B-space or M-space 
allocated as a descendant of the 
space. 

The amount of space to be allocated 
is specified as an exact number of 
bytes. The system may choose to al¬ 
locate storage in multiple-byte 
units in order to simplify internal 
mechanisms. The amount of space al¬ 
located may therefore not be exactly 
the same as that requested, and the 
difference may vary from one EPSILON 
system to another. However, in all 
cases the amount actually allocated 
will not be less than that requested. 

3.2 B-spaca Allocation 

B-space allocation is always indi¬ 
rect in the sense that it occurs only 
in connection with saving data in an 
M-space by means of the SAVE SPACE 
instruction (SAVE). SAVE is a modal 
instruction which can be executed 
within a C-process or an R-process. 
When executed within a C-process, it 
is entirely synchronous with respect 
to process state advancement. When 
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the instruction is completed: 

o a B-space equal in size to the 
referenced M-space has been al¬ 
located 

o the number of bytes in the space 
and the space pointer have been 
loaded into the arithmetic and 
pointer register fields of the 
specified general register 

o the contents of the referenced 
M-space have been stored into the 
allocated B-space. 

When executed within an R-process, 
SAVE is not entirely synchronous. It 
is completed as soon as the B-space 
has been allocated and the general 
register loaded; storage of the 
M-space data into the allocated 
B-space may not be complete, nor even 
in-process. Until data storage is 
complete, the newly allocated 
B-space is not available, and an ad¬ 
dressing exception will occur if it 
is referenced prior to completion. 
The LOAD POINTER instruction indi¬ 
cates space availability, and so can 
be used to avoid premature refei— 
ences. 

The B-space allocated by a SAVE in¬ 
struction inherits the attribute of 
being an ordinary or module space 
from the saved M-spaca. It also in¬ 
herits the protection vector, though 
some values may be altered. 

o The M-space may be in private or 
family custody of the process ex¬ 
ecuting the SAVE instruction; 
the B-space is always put into 
custody of the family of the pro¬ 
cess 

o if the read or write access of 
the M-space is private, the coi— 
responding B-space access is set 
as family; other access values 
are inherited unaltered. 


Although a B-space is assigned write 
access, the access is significant on¬ 
ly for M-space descendants of the 
space, as there are no instructions 
which copy data into an existing 
B-space. A descendant of a B-space 
is an M-space allocated during execu¬ 
tion of a LOAD or linkage instruction 
referencing the B-space, or a B-space 
allocated during execution of a SAVE 
instruction referencing an M-space 
descendant of the B-space, or any 
space allocated during the execution 
of a LOAD, linkage, or SAVE instruc¬ 
tion referencing a descendant of the 
B-space. 

The LOAD SPACE instruction (LOAD) is 
a modal instruction matched to the 
SAVE instruction. When executed 
within a C-process, it behaves like a 
SAVE instruction executed within a 
C-process with the roles of the 
B-space and M-space reversed. Thus, 
when the instruction is completed: 

o an M-space equal in size to the 
referenced B-space has been al¬ 
located 

o the number of bytes in the space 
and the space pointer have been 
loaded into the arithmetic and 
pointer register fields of the 
specified general register 

o the contents of the referenced 
B-space have been copied into the 
allocated M-space. 

Similarly, when executed within an 
R-process, it behaves like a SAVE in¬ 
struction executed within an R-pro¬ 
cess with the roles of the B-space 
and M-space reversed. In either 
case, the descendant M-space inhei— 
its without change both the pro¬ 
tection vector of the B-space and its 
atribute of being an ordinary or mod¬ 
ule space. 

A LOAD instruction can be applied to 
any B-space, whether an ordinary or 
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module space, and a new descendant 
M-space results from each applica¬ 
tion. New B-spaces can then be allo¬ 
cated by application of SAVE 
instructions to the M-spaces, so that 
descendant trees of any degree of 
complexity can be formed by use of 
the SAVE and LOAD instructions. 

A linkage instruction, however, can 
only be applied to a B-space with the 
module attribute, and a new descend¬ 
ant results only if one does not al¬ 
ready exist; thus, only one M-space 
copy of a module B-space need exist 
at any one time. The linkage in¬ 
structions are discussed in Chapter 
5. 

3.3 Pointers 

Pointers are generated only when new 
spaces are allocated by the instruc¬ 
tions ALLOC, SAVE, and LOAD. A new 
pointer is loaded into the pointer 
register designated in the allocat¬ 
ing instruction, where it is avail¬ 
able for use by the process within 
which the instruction was executed. 
Two instructions exist to make point¬ 
ers generally available. 

o The STORE POINTER instruction 
(SP) stores the contents of the 
designated pointer register into 
a word located in an M-space, 
where the pointer can be 
retrieved by any process having 
access to the space. 

o The LOAD POINTER instruction 
(LP) loads the contents of a word 
located in an M-space, presumed 
to be a pointer, into a desig¬ 
nated pointer register. 

Because a space cannot be referenced 
except through a pointer in a pointer 
register, the LP instruction is de¬ 
signed to indicate space availabili¬ 
ty, and to serve as the focal point 
for validation of access. The status 
of the space relative to the process 


is returned in the condition code set 
by the instruction, so that processes 
can avoid references which would 
cause exceptions. 

o Condition code zero indicates 

the process has both read and 
write access to the space 

o Condition code 1 indicates the 

process has access restricted to 
read or write 

o Condition code 2 indicates the 

space exists but is temporarily 
unavailable to the process 

o Condition code 3 indicates the 

space is not available to the 
process, either because all 
access is denied or the space 
does not exist. 

In order to allow optimization of in¬ 
struction execution performance, the 
status defined by an allocation 
instruction or returned by an LP in¬ 
struction is also retained by the 
system as the status associated with 
the use of the pointer register. The 
retained status is not changed if the 
relation between the process and the 
space changes (e.g. the space becomes 
available for addressing) until an¬ 
other LP referencing the register is 
executed. A process can therefore 
gain access to a space if it was pre¬ 
viously denied only by explicitly 
loading a pointer to the space into 
some pointer register. 

If a process has loaded a pointer and 
received an indication of space 
availability, it is still possible 
for access or addressing exceptions 
to occur if the space is not of the 
right type for the instruction. When 
there is doubt, the type may be de¬ 
termined by the TEST POINTER instruc¬ 
tion (TP), which returns data 
indicating what type of space is 
identified by the contents of a spec¬ 
ified pointer register. 
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3.4 Snaca Retrieval 

A space is automatically deleted from 
the system whenever its custodian is 
deleted ■ 

o a space in private custody is 
deleted during termination of 
the custodian process 

o a space in family custody is de¬ 
leted during deletion or modifi¬ 
cation of the process model for 
the family 

o a space in bound custody is de¬ 
leted with the process model to 
which it is bound. 

No explicit deletion request is re¬ 
quired of any process for such de¬ 
letion to occur. A space can also be 
explicitly deleted by execution of a 
FREE SPACE instruction (FREE) within 
any custodian process of the space. 

A legitimate deletion request, 
whether indirect or explicit, will 
always be accepted for any space. 
However, if the space is not avail¬ 
able for addressing because a previ¬ 
ous instruction has not been 
completed, or if the space contains a 
closed access control gate [Section 
5.103, deletion will be delayed until 
the space becomes eligible to return 
to normal status, without the return 
actually being made. 

Deletion will also be delayed until 
processes which have gained access to 
the space no longer need to reference 
it. For this purpose, reference re¬ 
quirements are measured in terms of 
pointer register usage. It is pre¬ 
sumed that a process will expect to 
continue to reference a space as long 
as a pointer granting access to the 
space resides in a pointer register 
of the process. Consequently, a ref¬ 
erence count is recorded and main¬ 
tained for each space. 


o The count is set to the value 1 
when the space is allocated, re¬ 
presenting the usage of the 
pointer register loaded by the 
allocation instruction. Allo¬ 
cation also sets a custody flag 
for the space. The space cannot 
be deleted as long as the custody 
flag is turned on. 

o The count is incremented by 1 
whenever a pointer granting ac¬ 
cess to the space is loaded into 
a pointer register of some pro¬ 
cess; it is decremented by 1 
whenever a pointer to the space 
is deleted from a pointer regi¬ 
ster in some process. An LP in¬ 
struction completed with 

condition codes zero or 1 will 
therefore cause the count of the 
space referred to by the pointer 
just loaded to be incremented, 
and the count of the space re¬ 
ferred to by the pointer dis¬ 
placed from the register, if any, 
to be decremented. 

o A FREE instruction substitutes a 
null pointer for any pointer to 
the referenced space in all 
pointer registers of the process 
executing the FREE, and the ref¬ 
erence count is decremented by 1 
for each substitution. The cus¬ 
tody flag is also reset, indicat¬ 
ing loss of custody. 

o During process termination 
counts are decremented by carry¬ 
ing out the equivalent of loading 
a null pointer into all pointer 
registers of the process. Custo¬ 
dy flags are reset by deletion 
requests generated for spaces in 
private custody of the process. 

A space is not actually deleted from 
the system until its custody flag is 
turned off and its reference count 
becomes zero. If a deletion request 
is accepted and the count does not go 
to zero at acceptance, references to 
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the space not involving data transfer 
are treated as if the space did not 
exist 1 

o an LP instruction will return 

condition code 3 

o all instructions requiring a 

process to have custody of the 
space f such as LOAD and SAVE) 
will cause exceptions or return a 
condition code indicating inval¬ 
id usage, as appropriate to the 
instruction. 

Deletion therefore always appears 
synchronous to the request. When a 
space is finally deleted, the storage 
associated with the space is returned 
to the M-storage or B-storage pool, 
as appropriate. 

Reference count protection is also 
applied to other instructions which 
result in transfer of custody, such 
as ENQUEUE [Section 5.8] and REQUEST 
INPUT/OUTPUT [Section 7.3]. 

3.5 Domain Identifier 

A domain is an unordered, non-empty 
collection of ordinary spaces. It 
begins existence with a single space, 
acquires new members through process 
activity, loses members as they are 
deleted from the system, and goes out 
of existence if all of its member 
spaces are deleted. The period of 
existence of a domain is not fixed, 
nor is there a limit to the number of 
members, either in total or at any 
given time. 

The criteria for membership in a do¬ 
main are not explicitly defined, so 
there is no information about the 
content of a space belonging to a 
given domain which is made use of by 
the system. Domains are simply re¬ 
cognised as entities for which mem¬ 
bership is propogated by rules 
relating spaces and processes. 


o Each domain has a domain narna and 
domain idontifier. The name is an 
arbitrary 32-bit referent sup¬ 
plied as data; the identifier is 
a 32-bit referent assigned by the 
system. The name is used only 
when a domain is formed, and is 
returned when the domain goes out 
of existence. All other refei— 
ences are by means of the identi¬ 
fier. 

o A domain is formed by the ASSIGN 
DOMAIN IDENTIFIER instruction 
(ASSIGN), which generates a new 
domain identifier and assigns it 
to a specified space. The space 
must be an ordinary space in cus¬ 
tody of the process executing the 
ASSIGN, and the name must be dis¬ 
tinct from all other domain 
names, or the assignment attempt 
will be rejected. 

o As a matter of convenience, a 
space which does not belong to a 
named domain is considered to be¬ 
long to an unspecified domain 
called the common domain. The 
value of the identifier (and also 
the name) of the common domain is 
zero; the value of other domain 
identifiers is not predictable. 

o The activity of any process is 
always considered to take place 
on behalf of the domain whose 
identifier has been acquired by 
the process. A process may ac¬ 
quire a permanent identifier or 
may be assigned a succession of 
identifiers. The specific rules 
for acquisition of identifier, 
which vary by process class, are 
given in Chapters 5, 6, and 7. 
In all cases, when a process with 
a given domain identifier allo¬ 
cates an ordinary space, the do¬ 
main is propogated by assigning 
that identifier to the allocated 
space. A module space is always 
assigned to the common domain. 
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o The domain identifier assigned 
to a space is retained until the 
space is deleted, unless the 
space is the object of an ASSIGN 
instruction and becomes the ini¬ 
tial space of a new domain. Any 
B-space or M-space allocated as a 
descendent of a space inherits 
the identifier current at the 
time of allocation. The identi¬ 
fiers of descendents are not al¬ 
tered by an ASSIGN applied to a 
space. 

o The membership count of a domain 
is sat to the value 1 by a suc¬ 
cessful ASSIGN, incremented by 1 
for every space added to the do¬ 
main, and decremented by 1 for 
every space removed from the do¬ 
main. If the count goes to zero, 
the domain is deleted from the 
system and a 'domain end' system 
exception is raised. The excep¬ 
tion process is supplied the 
resource usage statistics logged 
against the domain identifier 
C Section 9.3]. 

As it is possible to allocate any I/O 
device so that I/O requests will be 
accepted only from processes with a 
specified identifier [Section 7.9], 
these facilities allow domain iden¬ 
tification to be used as a basis for 
the definition, control, and ac¬ 
counting of work within an EPSILON 
system. As additional support for 
this function, the domain identifier 
of a space may be obtained by use of 
the LOAD DOMAIN IDENTIFIER instruc¬ 
tion (LDID), which places the identi¬ 
fier in the arithmetic register field 
of a designated general register. 

3.6 Changes of Custody 

The ALLOC instruction also provides 
options for the initial setting of 
the protection vector. It is possi¬ 
ble to request that the allocated 
M-space be assigned either to private 
custody of the process within which 


the allocation instruction was exe¬ 
cuted, or to custody of the family of 
that process. The same request can 
also be made for the read and write 
access, so that the initial pro¬ 
tection protection vector of an 
(1-space can have any one of the eight 
values from 

(private,private,private) 
to 

(family,family,family). 

The custodian process can then change 
the custody or access of the space by 
executing either a SET PROTECTION 
VECTOR instruction (SPV), or an EN¬ 
QUEUE instruction. 

The SPV instruction provides the 
means for direct alteration of the 
protection vector of an M-space or a 
B-space. The new protection vector 
of the space is the result of apply¬ 
ing the maximum function between the 
old protection vector and the pro¬ 
posed vector. The maximum is taken 
component by component, using numei— 
ical values for custody and access 
types of 

0 = private 

1 = family 

2 - domain 

3 = public. 

SPV operation is therefore always to¬ 
wards less restrictive protection 
for the space. Thus, the initial ap¬ 
plication of SPV to a space allows 
the custody to be enlarged to that of 
the family to which the custodian 
process belongs, and the read or 
write access to be set to any of the 
values family, domain, or public, but 
subsequent applications may have no 
effect at all. 

The ENQUEUE instruction provides the 
means to transfer custody of an 
M-space from one family to another. 
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although the transfer is indirect in 
the sense that the family associated 
with the queue is not known to the 
enqueuing process. Execution of an 
ENQUEUE will cause transfer of custo¬ 
dy to whatever process dequeues the 
space, at which time the protection 
vector will be set as if the space 
had been newly allocated by direct 
request of the dequeuing process. 

Once an M-space has been placed into 
family custody, any member of the 
family has custodian status, and so 
can execute an ENQUEUE or 5PV without 
causing an access exception. Since 
the SPV does not provide any way to 
change custody from family to pri¬ 
vate, the space can return to private 
custody only if transferred by means 
of ENQUEUE. 

Access, custody, and domain membei— 
ship are related in the following 
way. 

o A space with private access can 
be referenced for data access of 
that type (read or write) only by 
the original custodian process. 
If the space is transferred to 
family custody without enlarging 
the access to family, the other 
custodians cannot reference the 
space for that type of access. 
If the original custodian is de¬ 
leted, no process can then have 
that type of access unless custo¬ 
dy is transferred to another fam¬ 
ily. 

o A space with family access can be 
referenced for data access of 
that type by any member of the 
family. 

o A space with domain access can be 
referenced for data acces of that 
type only by a process whose 
domain identifier matches the 
identifier of the space. A 
custodian process has no special 
status in this case. 


o A space with public access can be 
referenced for data access of 
that type by any process. 

o A module space can be referenced 
by a process for instruction exe¬ 
cution only if the process has 
read access to the space. 

For purposes of access a space in 
bound custody is treated as if it 
were in custody of the family of the 
process model to which it is bound, 
though processes of the family are 
not, in fact, custodians of the 
space. Neither SPV nor ENQUEUE can 
be used to place a space into bound 
custody. A space becomes bound to a 
process model when the model is de¬ 
fined; once bound, it cannot be re¬ 
turned to private or family custody. 

3.7 instruction Descriptions 

The following are detailed descrip¬ 
tions of the function and behavior of 
the storage and space instructions. 
These descriptions are in the same 
format as the instruction descrip¬ 
tions in POP360, except that the in¬ 
struction picture and operation code 
have been omitted, and a category has 
been added specifying the process 
classes within which the instruction 
can be executed. To save repetition, 
the following exception descriptions 
common to all instructions have been 
omitted from the text, and are not 
specifically listed under the head- 
ing 'Except ions': 

o if an attempt is made to execute 
an instruction by a process be¬ 
longing to a process class which 
is not allowed execution rights, 
the instruction is suppressed 
with an operation exception 

o if an attempt is made to refet— 
ence a space through a pointer 
register with an invalid access 
status for the type of reference. 
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the instruction is suppressed 
with an access exception 

o if a pointer register expected to 
designate an M-space (B-space) 
actually contains a pointer to a 
B-space (M-space), the instruc¬ 


tion is suppressed with a spec¬ 
ification exception. 

Suppression of an instruction causes 
the exception to be taken before the 
state vector is altered or data in 
storage has been modified. 




ALLOCATE SPACE 


ALLOC Ml,R2 <RR> 

The M-storage pool is examined for a contiguous block of storage of extent 
not less than the number of bytes specified in arithmetic register R2. If the 
request exceeds the total amount of available M-storage installed, the in¬ 
struction is terminated with condition code 2. If the request could be met 
but no block of sufficient size is currently available, the instruction is 
terminated with condition code 1. 

If a block is available an M-space is allocated to fulfill the request. 
The custody flag of the space is turned on, and the reference count is set to 
the value 1. If the space is an ordinary space, it is assigned the domain 
identifier of the process within which the instruction is being executed. If 
the space is a module space, it is assigned to the common domain. The membei— 
ship count of the assigned domain is incremented by 1. 

The four bits of the mask field Ml specify attributes of the allocated 
space. If the high-order bit is 1 the space is designated as a module space, 
otherwise it is an ordinary space. The three remaining bits indicate initial 
assignments for protection vector values, corresponding in high to low order 
respectively to custody, read access, and write access. If a bit is zero, the 
corresponding position of the protection vector is set to private, referring 
to the process within which the instruction is executed; if the bit is 1, the 
corresponding position is set to family, referring to the family of that pro¬ 
cess . 

The actual extent of the allocated space, which is not less than that re¬ 
quested, then replaces the contents of arithmetic register R2, a pointer to 
the space is loaded into pointer register R2, and the instruction is completed 
with condition code zero. 

Process Class: C,R,D 

Condition Code: 

0 Space Allocated 

1 M-storage not currently available 

2 Request cannot be fulfilled 

3 

Exceptions: None 
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FREE SPACE 


FREE R2 <RR> 

The space designated by pointer register R2 is deleted from the system and 
the storage associated with the space returned to the storage pool correspond¬ 
ing to the type of space deleted. 

If the requesting process is not a custodian of the space the instruction 
is suppressed with an access exception. It is suppressed with a data excep¬ 
tion if the space is in I/O request state [section 7.31. 

If the instruction is not suppressed, the custody flag of the space is 
turned off. A null pointer is loaded into pointer register R2 and into any 
other pointer register of the process, which contains a pointer to the space, 
and the instruction is completed by decrementing the reference count by 1 for 
each null pointer loaded. 

Deletion of the space will occur when both the reference count and the 
gate count [5ection 5.11] are zero, which may be prior to completion of the 
instruction or at some later time. When the space is deleted, the membership 
count of the domain to which it belongs is decremented by 1. If the count be¬ 
comes zero, the domain is deleted from the system and a domain end system ex¬ 
ception is raised. In any event, an attempt by any process to load a pointer 
to the space after the custody flag has been turned off will be rejected. Ref¬ 
erences to data in the space by addresses generated through pointer registers 
loaded before the flag was turned off will be valid until the space is actual¬ 
ly deleted. 

Process Class'- C,R,D 

Condition Code: Unchanged 

Exceptions : 

Access 

Data 

Domain end (system) 


SAVE SPACE 


SAVE R1,R2 <RR> 

The B-storage pool is examined for a contiguous block of storage of extent 
not less than the number of bytes in the M-space designated by pointer regi¬ 
ster Rl. If the request exceeds the total amount of available B-storage 
installed, the instruction is terminated with condition code 3. If the re¬ 
quest could be met but no block of sufficient size is currently available, the 
instruction is terminated with condition code 2. If the requesting process is 
not a custodian of the designated M-space, the instruction is suppressed with 
and access exception. 

If a block is available, a B-space is allocated to fulfill the request. 
The newly allocated space inherits the protection vector, custodians, domain 
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identifier, and ordinary or module attribute from the referenced M-space. The 
protection vector of the B-space is then examined, and any values of private 
are changed to values of family. The extent of the space, which is at least 
that of the referenced M-space, is placed into arithmetic register R2 and a 
pointer to the space is placed into pointer register R2. The reference count 
of the space is set to the value 1, its custody flag is turned on, and the mem¬ 
bership count of the domain is incremented by 1. 

If the instruction is executed within a C-process, the contents of the 
M-space are then copied into the newly allocated B-space, and the instruction 
is completed with condition code zero. 

If the instruction is executed within an R-process, a request is made to 
copy the contents of the M-space into the newly allocated B-space, and the i n- 
struction is completed with condition code 1. The B-space is not available 
for addressing until data transfer from the M-space is complete, and an ad¬ 
dressing exception will occur if it is prematurely referenced. The availabil¬ 
ity status can be tested by loading the space pointer into a pointer register. 
The contents of the B-space are not predictable if the M-space contents are 
altered after completion of the instruction but prior to completion of the da¬ 
ta transfer. 

Process Class: c,R 

Modal 


Condition Code: 

0 Space saved 

1 Space allocated 

2 B-storage not available 

3 Request cannot be fulfilled 

Exceptions: 

Access 


LOAD SPACE 


LOAD R1,R2 <RR> 

The M-storage pool is examined for a contiguous block of storage of extent 
not less than the number of bytes in the B-space designated by pointer regi¬ 
ster Rl. If the request exceeds the total amount of available M-storage 
installed, the instruction is terminated with condition code 3. If the re¬ 
quest could be met but no block of sufficient size is currently available, the 
instruction is terminated with condition code 2. If the requesting process is 
not a custodian of the designated B-space, the instruction is suppressed with 
an access exception. 

If a block is available, an M-space is allocated to fulfill the request. 
The newly allocated space inherits the protection vector, custodians, domain 
identifier, and ordinary or module attribute from the referenced B-space. The 
extent of the space, which is at least that of the referenced B-space, is 
placed into arithmetic register R2 and a pointer to the space is placed into 
pointer register R2. The reference count of the space is set to the value 1, 
its custody flag is turned on, and the membership count of the domain is in- 
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cremented by 1 . 

If the instruction is executed within a C-process. the contents of the 
B-space are then copied into the newly allocated M-space, and the instruction 
is completed with condition coda zero. 

If the instruction is executed within an R-procsss, a request is made to 
copy the contents of the B-space into the newly allocated M-space, and the in¬ 
struction is completed with condition code 1. The M-space is not available 
for addressing until data transfer from the B-space is complete, and an ad¬ 
dressing exception will occur if it is referenced prematurely. The availabil¬ 
ity status can be tested by loading the space pointer into a pointer register. 

Process Class: C,R 

Modal 


Condition Code 1 

0 Space saved 

1 Space allocated 

2 M-storage not available 

3 Request cannot be fulfilled 

Exceptions: 

Access 


STORE POINTER 


SPR R1,R2 <RR> 

SP R1,D2CX2,B2) <RX> 

The contents of pointer register R1 are stored into the word at the second 
operand location. 

In the RR form of the instruction, the second operand is arithmetic regi¬ 
ster R2. Pointer register R2 is not disturbed. 

Process Class 1 C,R,D 

Condition Code: Unchanged 

Exceptions: None 


LOAD POINTER 


LPR R1,R2 <RR> 

LP R1,D2(X2,B2) <RX> 

The instruction is suppressed with a specification exception if the format 
of the second operand is not consistent with a pointer. It is terminated with 
condition code 3 if the space is not available to the process because it does 
not exist, is being deleted, or the process does not have access to it, and 
with condition code 2 if the space is temporarily unavailable to the process. 
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If the space is available to the process, pointer register R1 is examined 
and if it contains a pointer the reference count of the identified space is 
decremented by 1. If decrementing causes the count to become zero, if the 
custody flag is off, and if the gate count is zero, deletion of the space will 
occur as described for the FREE SPACE instruction. 

The second operand is then loaded into R1 and the reference count of the 
identified space is incremented by 1. In the RR form of the instruction, the 
second operand is arithmetic register R2. 

The instruction is completed with condition code zero if the process is 
allowed both read and write access to the space, and with condition code 1 if 
access is restricted to read or write only. 

Process Class: C,R,D 

Condition Code 1 

0 Full access granted 

1 Restricted access granted 

2 Space temporarily unavailable 

3 Space not available 

Exceptions: 

Specification 

Domain end (system) 


TEST POINTER 


TP R1,D2(X2,B2) <RX> 

The instruction is terminated with condition code 3 if pointer register R1 
contains a pointer to a space temporarily unavailable to the process within 
which the instruction is being executed, and with condition code 2 if the reg¬ 
ister contains a null pointer. 

If the instruction is not terminated, a byte of descriptive data is stored 
at the location designated by the second operand. The instruction is then 
completed with condition code zero if the space is an M-space, and with condi¬ 
tion code 1 if the space is a B-space. 

The byte of stored data describes the relation of the space to the pro¬ 
cess. The high-order bit is zero if the space is an ordinary space, and 1 if 
it is a module space. Bit 1 is zero if the process is not a custodian of the 
space, and 1 if it is; bit 2 is zero if the process does not have read access 
to the space, and 1 if it does; bit 3 is zero if the process does not have 
write access, and 1 if it does. The remaining bits of the byte are set to ze¬ 
ro . 
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Process Class 1 C,R,D 

Condition Code: 

0 M-space data stored 

1 B-space data stored 

2 Null space 

3 Space temporarily unavailable 
Exceptions 1 None 


ASSIGN DOMAIN IDENTIFIER 


ASSIGN R1,R2 <RR> 

The instruction is suppressed with an access exception if the requesting 
process is not a custodian of the space designated by pointer register R2, and 
with a specification exception if the space is not an ordinary space. 

If the instruction is not suppressed, the contents of arithmetic register 
R1 are compared with the list of domain names. If there is a match, the in¬ 
struction is terminated with condition code 1. If there is no match, an iden¬ 
tifier is generated for a new domain with the specified name. The identifier 
replaces the contents of arithmetic register Rl. 

The membership count of the new domain is set to the value 1. The new do¬ 
main identifier replaces the domain identifier previously assigned to the 
space, and the membership count of the old domain is decremented by 1. If dec¬ 
rementing reduces the count to zero, the domain is deleted from the system and 
a domain end system exception is raised. The instruction is then completed 
with condition code zero. 

Process Class: C,R 

Condition Code: 

0 Identifier assigned 

1 Domain already exists 

2 

3 

Exceptions : 

Access 

Specification 

Domain end (system) 


LOAD DOMAIN IDENTIFIER 


LDID Rl,R2 <RR> 

The domain identifier of the space designated by pointer register R2 re¬ 
places the contents of arithmetic register Rl. 
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Process Class 1 C,R 
Condition Code : Unchanged 
Exceptions 1 None 


SET PROTECTION VECTOR 


SPV Ml,R2 <RR> 

If the requesting process is not a custodian of the space, the instruction 
is suppressed with an access exception. Otherwise, the protection vector of 
the space designated by pointer register R2 is modified according to the con¬ 
tents of arithmetic register R2, under control of mask field Ml. 

The high-order bit of field Ml is ignored. The three remaining bits indi¬ 
cate assignments for protection vector values, corresponding in high to low 
order respectively to custody, read access, and write access. If a bit is ze¬ 
ro, the corresponding position of the protection vector is to remain unal¬ 
tered; if a bit is 1, the position is altered as determined by arithmetic 
register R2. 

The bytes of the register, numbered 0,1,2,3 from left to right, correspond 
to the bits of field Ml. Byte 0 is therefore ignored, and bytes 1, 2, and 3 
contain values for custody, read access, and write access. The low-order bit 
of byte 1 and the two low-order bits of bytes 2 and 3 specify the request as 

0 = private 

1 = family 

2 = domain 

3 = public 

For any position of the vector which is to be altered, the new value assigned 
corresponds to the numerical maximum of the existing value and the requested 
value. 

Process Class : C,R 

Condition Code: Unchanged 

Exceptions: 

Access 


INSERT PROTECTION VECTOR 


IPV R2 <RR> 

The protection vector of the space designated by pointer register R2 is 
inserted into arithmetic register R2. 

The high-order byte of the register is set to the value zero if the space 
is an M-space, and to the value 1 if the space is a B-space. The three remain- 
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ing bytes correspond in high to low order respectively to custody, read ac¬ 
cess, and write access. The protection vector components are inserted into 
the two low-order bits of the corresponding bytes using the values 

0 = private 

1 = fami ly 

2 = domain (access) or bound (custody) 

3 = public 

The four high-order bits of each of the bytes are set to zero. The instruction 
is completed with condtion code zero if the space is an M-space, and with con¬ 
dition code 1 if it is a B-space. 

Process Class 1 C,R 

Condition Code 1 

0 M-space vector inserted 

1 B-space vector inserted 

2 
3 

Exceptions 1 None 
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4.0 PROCESS DISPATCHING 

During its lifetime, a process is ei¬ 
ther advancing from state to state 
because a processing mechanism is 
acting upon the instruction sequence 
associated with the process, or else 
it is suspended in some state waiting 
for assignment of a processing mech¬ 
anism. The activity involved in the 
assignment of a processing mechanism 
to processes is called process dis¬ 
patching. 

Apart from the option of defining 
scheduling algorithms at system in- 
i t i al i zat i on, dispatching is carried 
out by the system as a closed func¬ 
tion, using data supplied in process 
models and data reflecting the cui— 
rent status of the system. Dispatch¬ 
ing discipline varies with process 
class; for C-processes, dispatching 
is essentially time-driven, while 
for R-processes and D-processes it is 
event-driven. This difference is 
typical of the different kind of ac¬ 
tivity visualized for the process 
classes. 

This chapter describes CPU assign¬ 
ment, and the relation between C-pro- 
cess dispatching and R-process 
dispatching. D-process dispatching 
is discussed in Chapter 7. 

4.1 Computation Cycles 

A C-proeess is viewed by the system 
as an activity which transforms data 
from a given input form to some spec¬ 
ified output form. The process may 
exist only for a single transforma¬ 
tion, but in general its life will 
extend over a series of transforma¬ 
tions. A simple and natural way to 
describe the CPU requirements of such 
processes is in terms of time con¬ 
straints for completion of a trans¬ 
formation. For example, if the 
function of a particular process is 
to receive messages and distribute 


them to other processes on the basis 
of decoding a field in the message, 
and if ten messages a second can be 
expected, then the process must be 
assigned a CPU often enough to com¬ 
plete an average of one transforma¬ 
tion every 100 milliseconds. 

Such a description is intrinsic to 
the process and independent of other 
processes, but provides no basis for 
relating process requirements to one 
another, as the transformation cai— 
ried out by a process is chosen arbi¬ 
trarily. However, any period of time 
shorter than an intrinsic time con¬ 
straint will fulfill the same re¬ 
quirement, and any such shorter time 
can be chosen to be a multiple of 
some fixed unit of time. These 
observations form the basis for the 
introduction of time into C-process 
dispatching. 

o The fixed unit of time is called 
a basic cycle. The length of the 
basic cycle is specified at sys¬ 
tem initialization, and can be 
changed only by 

re-initialization. Its value 

must be larger than the time tak¬ 
en to execute the dispatching 
function by that model of EPSILON 
system, but is otherwise not re- 
stricted. 

o The time constraint of any pro¬ 
cess is specified in terms of a 
length of time called a computa¬ 
tion cycle. The number of compu¬ 
tation cycles and the length of 
each cycle is also specified at 
system initialization. 

The computation time, T, alloted to 
each computation cycle is a multiple 
of the basic cycle time, t. That is, 

T = Nt. 
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The integer N, which can range be¬ 
tween 1 and 16,777,215, is called the 
period of the computation cycle. 
Each cycle is also assigned a unique 
8-bit identifier, so that a system 
may have as many as 256 separata com¬ 
putation cycles. The association of 
a process with a computation cycle 
then occurs as follows 1 

o every C-process model designates 
a computation cycle by specifi¬ 
cation of its identifier 

o all members of a process family 
are assigned to the computation 
cycle identifed by their process 
model. 

There are no instructions which will 
change the assignment of a process, 
once initiated, from one computation 
cycle to another. Change can only 
affect processes not yet initiated, 
as the result of changing the process 
model association through use of the 
DEFINE C-PROCESS MODEL instruction. 

4.2 C-process Dispatching Overview 

The overall structure of C-process 
dispatching is represented by the 
schematic of figure 4.1. 

The objective of this structure is to 
furnish enough function to provide a 
useful service, but not so much func¬ 
tion as to preclude any algorithm for 
apportionment of CPU time considered 
equitable by managers of a system. 

The basic concept behind the struc¬ 
ture is to treat computation cycle 
periods as time constraints for 
selecting processes to be allocated a 
CPU. Every process assigned to a 
given computation cycle is to be se¬ 
lected, or considered for selection, 
once every period of the cycle. Fig¬ 
ure 4.1 can therefore be visualized 
as the flow of control through a con¬ 
tinuing activity of the system gov¬ 
erned by those time constraints, and 


with the following general behavior. 

o Dispatching activity is trig¬ 
gered whenever a condition 
arises which forces a process 
switch (e.g. an I/O wait), and at 
the beginning of every basic cy¬ 
cle. The basic cycle is there¬ 
fore the maximum time that can 
elapse between attempts to as¬ 
sign a CPU to a C-process. 

o The function of entry service is 
to initiate a process to service 
overrun of the computation cycle 
time constraints, should it oc¬ 
cur, and to serve as a control 
point to idle if there is no pro¬ 
cess to dispatch. 

o If there has been any request for 
initiation of a C-process since 
the previous cycle of dispatch¬ 
ing activity, initiation service 
is invoked. Its function is to 
generate initial state vector 
data and to assign the resulting 
process to the appropriate com¬ 
putation cycle. As the process 
model may not have been in recent 
use, and the initial instruction 
sequence is not required to be 
pre-loaded into an M-space, ini¬ 
tiation of a particular process 
can require a complex sequence of 
actions extending over many cy¬ 
cles of dispatching activity 
C Sect ion 5.4], 

o Selection of a process, which is 
called scheduling, consists of 
first selecting a computation 
cycle, then a process within the 
cycle. For this purpose, the 
computation cycles are sequenced 
in order of period, from smallest 
to largest. Initially, the cycle 
with the smallest period is cho¬ 
sen and processes are selected 
from it. Processes continue to 
be selected from that cycle until 
an indication is given by the 
scheduling mechanism that the 
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WAIT FOR TRIGGER 
(process switch 
or end of basic 
cycle) 


§ 


ASSIGN CPU 
TO PROCESS 


§ 


ENTRY SERVICE 


§ 


INITIATION 

SERVICE 


§ 


SELECT PROCESS 


COMPUTATION 
CYCLE SELECT 


Figure 4.1 

Schematic of C-process 
Dispatching Activity 


list of processes assigned to the 
cycle is exhausted. If time then 
remains before expiration of the 
period, the next cycle in se¬ 
quence is chosen. If the period 
expires before the process list 
is exhausted, a computation cy¬ 
cle overrun condition may exist; 
in that event, selection remains 
with the same cycle rather than 
proceeding to the next. 

Selection activity continues in 
this way until all computation 
cycles are exhausted, which 
causes dispatching to idle, or 
until expiration of a basic cy¬ 
cle, which forces 
re-consideration of the initial 
computation cycle. In passing 
from one cycle to the next, if 
the new cycle has been previously 
completed, it will not be 
re-started again until expira¬ 
tion of its current period. Fur¬ 
thermore, a given cycle will not 
be reached until all previous cy¬ 


cles have completed their cui— 
rent periods. The overall effect 
of this procedure is to multiplex 
CPU allocation for all computa¬ 
tion cycles preceding any given 
cycle within each period of that 
cycle. 

o Since an optimal selection pro¬ 
cedure is quite dependent on ap¬ 
plication mix, the algorithm 
used to select a process within a 
computation cycle is not fixed. 
Each computation cycle has an as¬ 
sociated microprogram routine, 
called a selection routine, 
which implements the scheduling 
algorithm for that cycle. Se¬ 
lection routines are specified 
at system initialization, either 
as one of three standard rou¬ 
tines, or as a feature routine. 

It is the selection routine cf a 
computation cycle which deter- 
mi nes 
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what process has been se¬ 
lected, i f any 

whether or not the process 
list is exhausted. 

As a routine is not restricted in 
the algorithm by which it detei— 
mines these conditions, the sig¬ 
nificance of any computation 
cycle period is actually defined 
by the selection routine for the 
cycle. 

o Once a process has been selected, 
a CPU is assigned to it. Assign¬ 
ment consists of loading the 
state vector of the process into 
the local storage and registers 
of the CPU, causing execution of 
the currently associated in¬ 
struction sequence to resume 
from the point of previous sus¬ 
pension. Dispatching activity 
then idles until another entry 
trigger occurs. 

Execution of the instruction se¬ 
quence of a selected process will 
continue until a process switch is 
required, or until a basic cycle ex¬ 
pires. The average duration of pro¬ 
cess activity therefore depends 
primarily on the instruction se¬ 
quence and CPU speed, so that ex¬ 
pression of intrinsic time 
constraints in terms of computation 
cycle periods is normally a direct 
conversion. 

4.3 Dispatching Condition 

Although a selection routine may im¬ 
plement any scheduling algorithm in 
principle, in practice its behavior 
is constrained by the dispatching 
condition of the processes which are 
candidates for selection. The condi¬ 
tion of a C-process is : 

o running, if a CPU is assigned to 
it 


o waiting, if some event must occur 
before instruction execution can 
proceed 

o ready, if neither running nor 
waiting. 

The running and ready conditions 
arise out of dispatching action, but 
waiting conditions result from in¬ 
struction execution. There are two 
kinds of waiting condition. An 
implicit wait occurs when instruc¬ 
tion interpretation is delayed until 
some condition is met, at which time 
the instruction will be completed. 
When that occurs, the process is said 
to be suspended. An explicit wait is 
one which results from a condition 
generated by completion of an in¬ 
struction. Waiting conditions are 
further subdivided into five 
classes. 

o I/O Wait. The process is waiting 

for completion of a LOAD, SAVE, 
CALL or REQUEST INPUT/OUTPUT in¬ 
struct i on. 

o Gate Wait. The process is wait¬ 

ing for completion of a CLOSE 
GATE instruction, giving it ac¬ 
cess to data under control of an 
access control gate. 

o Exception Wait. The process is 

suspended until completion of an 
exception process initiated by a 
FORCE SYSTEM EXCEPTION instruc¬ 
tion. 

o Queue Wait. The process is wait¬ 

ing for data to be entered into a 
specified queue. The wait was 
initiated by execution of a QUEUE 
WAIT instruction, and will end 
with arrival of the data. 

o General Wait. The process is 

waiting for an unspecified 
occurrence. The wait was initi¬ 
ated by execution of a WAIT in¬ 
struction; it will end whenever 
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an initiation request is re¬ 
corded for the process. 

Assignment of a CPU to a process only 
makes sense, therefore, if the pro¬ 
cess is in ready condition. So if 
the basic operation of a scheduling 
algorithm results in picking a pro¬ 
cess that is running or waiting, the 
selection routine should take action 
to select another process, and should 
continue selecting until a ready pro¬ 
cess is found or the computation cy¬ 
cle list is exhausted. All useful 
scheduling algorithms obey this 
constaint. 

4.4 Selection Routines 

Standard selection routines are sup¬ 
plied with all EPSILON systems which 
implement simple scheduling algo¬ 
rithms of fairly wide applicability. 

Finite Sequential 

Processes in the computation cy¬ 
cle are selected in a sequence 
determined by a sequencing num¬ 
ber supplied in the process mod¬ 
el. The first process is 
selected at the beginning of a 
period, the second at next entry, 
the third at next entry, and so 
on. If a process is not ready at 
selection, it is bypassed in fa¬ 
vor of the next in sequence. 
Once selected or bypassed, a pro¬ 
cess will not be considered again 
until the next period, so the 
routine returns a list exhausted 
indication when the last process 
in sequence has been examined. 

This algorithm amounts to a 
round-robin each period, with 
slack time in the period filled 
in by processes from computation 
cycles of larger period. 

Infinite Sequential 

Process sequence is determined 


as in the finite algorithm; how¬ 
ever, selection starts at the 
first in sequence at every entry, 
the process chosen being the 
first one encountered in ready 
condition. A list exhausted con¬ 
dition is never returned unless 
there is no ready process in the 
computation cycle. 

This algorithm is the same as one 
often called 'priority schedul¬ 
ing'. It blocks access to compu¬ 
tation cycles of larger period 
unless the cycle is dormant, in 
effect extending the selection 
period indefinitely beyond the 
nominal cycle time. The expected 
usage is for the last computation 
cycle, where 'background' pro¬ 
cesses, if they exist, would 
normally be placed. 

Multiplexed 

Processes are assigned a weight¬ 
ing factor, supplied in the pro¬ 
cess model, which specifies the 
relative proportion of the com¬ 
putation cycle to be assigned to 
the process. The algorithm se¬ 
lects a process as many times in 
a cycle as the proportionality 
factor indicates, spreading the 
selections as evenly as possible 
throughout the period. An indi¬ 
cation to use the next cycle for 
one selection is returned when¬ 
ever a selected process is not 
ready or when slack time occurs 
? n the period. 

This algorithm is a weighted 
round-robin, with slack time 
spread throughout the period and 
filled in by processes from com¬ 
putation cycles of larger peri¬ 
od. 

All three selection routines treat 
processes in a gate wait condition as 
a special case, in order to apply a 
promotion technique to empty the gate 
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queue as rapidly as possible. This 
technique is discussed in Section 
5.10. 

4.5 C-process Dispatching Example 

In a particular system there are 
three computation cycles, one of pe¬ 
riod 2, one of period 3, and one of 
period 5. The finite sequential al¬ 
gorithm is used for the first two cy¬ 
cles, and the infinite sequential for 
the last. Process 1 is assigned to 
the first cycle, processes 2 and 3 to 
the second, process 4 to the last. 

Figure 4.2 illustrates one of the 
possible flows of control if the sys¬ 
tem has a single CPU. The bottom 
line represents time divided into 
basic cycles, with numbers marking 
the end of each cycle. The three up¬ 
per lines show allocation of the CPU 
to processes in the respective compu¬ 
tation cycles. Pointed right brack¬ 
ets designate the beginning of a 
computation cycle period, and colons 
within a period indicate computation 
cycle selection. 

In this example 

o Process 1 was not assigned a CPU 
during the fourth period of its 
computation cycle because it re¬ 
turned a WAIT during basic cycle 
5 which was not resolved until 
after basic cycle 8 had started. 

o The CPU becomes idle during basic 
cycle 6 when process 4 enters I/O 
wait, and stays idle until the 
next computation cycle period 
starts. 

o Process 2 is time-sliced at the 
end of basic cycle 1 and is not 
assigned the CPU again until the 
next period; process 3 is treated 
the same way at the end of basic 
cycle 7. Process 4, however, 
having come out of I/O wait dui— 
ing basic cycle 7, is assigned 
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the CPU during basic cycle 8 
becaue of the behavior of the in¬ 
finite sequential algorithm. 

Figure 4.3 illustrates a control flow 
for the same case if the system has 
two CPU. In this figure, two sets of 
three lines are used to show allo¬ 
cation of the CPU to processes in the 
respective computation cycles. The 
first set of lines shows allocation 
of the first CPU, while the second 
set corresponds to the second CPU. 
The time-slicing behavior of the fi¬ 
nite algorithm is more apparent here. 

This simple example is designed to 
show the multiplexing effect of com¬ 
putation cycle dispatching on C-pro¬ 
cess execution. It does not show the 
possibility of computation cycle 
overrun, nor the effect of R-process 
dispatching. 

4.6 R-process Dispatching 

An R-process is viewed by the system 
as an activity which reacts to the 
occurrence of some recognized event. 
The process is expected to exist only 
as long as necessary for the initial 
response, and to cause a C-process to 
be invoked to carry out any addi¬ 
tional activity which may be re¬ 
quired. A natural way to describe 
the CPU requirements of such pro¬ 
cesses is in terms of response prioi— 
ities, where higher priority is 
equated to greater urgency. Conse¬ 
quently, every source of R-processes 
is assigned a priority with respect 
to the other sources. The assignment 
is set up during system initializa¬ 
tion, and cannot be changed by in¬ 
struction execution. 

It is also a consequence of this view 
that the initiation of an R-procass 
coincides with the initial assign¬ 
ment of a CPU, and that a CPU switch 
will occur only if required to serv¬ 
ice a higher priority event. In¬ 
struction behavior within 
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C-process Dispatching 
Single CPU Example 


>1 > 

>1 

> 

> 3 

> 44:4444:4 

>2222 

> 

> 

> >11 

> 

> 

>2222 

>33 

> 

> 

4444>4444 

0-1-2. . . 

.3_4. . 

.5-6 


Figure 4.3 

C-process Dispatching 
Two CPU Example 


R-processes is therefore defined so 
that there are no explicit waiting 
conditions; an R-process is either 
running, or is ready to run as soon 
as a CPU can be switched back to it. 
The overall behavior of R-process 
dispatching is then as follows. 


o In order for a process to be ini¬ 
tiated as the result of occui— 
rence of an event associated with 
a process source, a process model 
must be connected to the source 
using the CONNECT R-PROCESS MOD¬ 
EL instruction. If a process 
model is not connected then any 
occurrence of an event associ¬ 
ated with the source is ignored. 


o A source becomes pending if a 
process model is connected and an 
associated event occurs. It is 
removed from pending status by 
initiation of a process from the 
connected process model. If an 
associated event arises while a 
source is pending only a single 
pending status will result. A 
source is said to be active if at 
least one member of the family of 
the connected process model is in 
existence. 

o An R-process model specifies 
whether or not more than one mem¬ 
ber of the family can exist at 
the same time. If a 

single-instance process modal is 
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connected to a source, a pending 
condition for the source will not 
become effective while the 
source is active. A pending con¬ 
dition for a source connected to 
a multi-instance process model 
is immediately effective if the 
number of instances in existence 
is less than the number of CPU in 
the system; otherwise it becomes 
effective as soon as one of the 
processes is terminated. 

o Initiation of a process for a 
pending source occurs as soon as 
the pending condition is effec¬ 
tive and a CPU is available for 
assignment to the process. A CPU 
is available if it is idle. A 
CPU is made available by suspen¬ 
sion of a runnning process if the 
running process is 

a C-process, or 

an R-process initiated by a 
source of . lower priority 
than the pending source. 

Suspension occurs in the order 
just described, and in reverse 
priority order within the R-pro¬ 
cess set. Multiple pending 
sources are taken in priority or¬ 
der . 

o Suspended processes are dis¬ 
patched as soon as a CPU is 
available and there are no pend¬ 
ing sources of higher priority. 
Dispatching is normally in re¬ 
verse order of suspension. How¬ 
ever, if a process is holding an 
access control gate, and if the 
gate has been requested by a 
higher priority process, a pro¬ 
motion technique is used to clear 
the gate. This technique is dis¬ 
cussed in Section 5.10. 

Execution of the instruction se¬ 
quence of an R-process will continue, 
with or without periods of suspen¬ 


sion, until the process terminates. 
Suspension is an internal condition 
which does not affect the functional 
behavior of a process. The only 
observable effect is that the execu¬ 
tion time of the instruction sequence 
is longer than if suspension had not 
occurred. 

4.7 Computation Cycle Overrun 

Because all R-processes take preced¬ 
ence over all C-processes in assign¬ 
ment of CPU, the execution time of 
C-processes as observed by C-process 
dispatching includes all time the 
processes are suspended in favor of 
R-processes. Computation cycle 
scheduling therefore provides a 
measure of the total CPU utilization 
of the system, not just the part de¬ 
voted to C-processes, so a computa¬ 
tion cycle overrun indicates some 
degree of system overload. 

Whether or not the overload requires 
remedial action depends on the pro¬ 
cessing environment and application 
mix. To service this dependence, a 
system overrun exception will be 
raised when an overrun condition is 
established. Data for the process 
model to be connected to the excep¬ 
tion is specified at system initial¬ 
ization. In addition, as part of the 
specification of the computation cy¬ 
cle structure, two parameters can be 
adjusted to avoid unnecessary initi¬ 
ation of an overrun process. 

The first parameter is a set of 8-bit 
integers, one for each computation 
cycle, called the overrun sequence 
counts. If a count is zero, an ovei— 
run for the associated cycle will be 
ignored. If a count is non-zero, it 
specifies the number of successive 
times an overrun for the associated 
cycle must be recorded before an 
overrun condition is established for 
that cycle. 

Sequence counts provide a simple way 
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of masking bursts of R-process activ¬ 
ity which only temporarily overload 
the system. Such burst will usually 
occur in all systems because of the 
stochastic distribution of events in 
time, but unless the average value of 
occurrences keeps activity high 
enough, the system is not really 
overloaded and the overrun indi¬ 
cation will be damped out. Figure 
4.4 illustrates this effect using the 
example of figure 4.2, with the addi¬ 
tion of comma symbols to designate 
assignment of the CPU to some R-pro¬ 
cess . 

In this example, process 1 is not as¬ 
signed the CPU during the second pe¬ 
riod of computation cycle 1 and 
process 3 gets no CPU time for the 
first two periods of computation cy¬ 
cle 2, but by the end of basic cycle 
12 the control flow will have 
returned to the basic pattern of fig¬ 
ure 4.2. There is no need to invoke 
an overrun process unless one of the 


period multiples is an absolute time 
constraint. 

The second parameter i s the overrun 
cycle indicator. If this indicator 
is set equal to the identifier of 
some computation cycle, then an ovei— 
run of any cycle beyond the indicated 
one will be ignored, whether or not 
the overrun is established by se¬ 
quence count. If the indicator is 
not equal to some identifier, all es¬ 
tablished overruns are effective. 
The cycle indicator provides a direct 
way of ignoring computation cycles 
whose time constraints are only nomi¬ 
nal . 

A system overrun condition is consid¬ 
ered to be established whenever an 
overrun condition is established for 
a computation cycle within the range 
designated by the overrun cycle indi¬ 
cator. The scope of activity of the 
resultant overrun process is de¬ 
scribed in Section 9.4. 
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5.0 C-PROCESSES • GENERAL COMPUTATION 

The behavior of a process is detei— 
mined partly by the instructions 
available for execution, and partly 
by built-in functions of the system. 
The behavior patterns favored by the 
system functions and their associ¬ 
ated conventions and protocols vary 
by process class, and for each class 
reflect a system view of the kind of 
activity appropriate to the class. 

The view of C-processes as primarily 
data transformation activities is 
therefore carried beyond process 
dispatching, into initiation, 

structure, linkage, access to shared 
data, and exception handling. More¬ 
over, as a data transformation is of 
little use without data, queuing fa¬ 
cilities provide for explicit flow of 
data between processes, and as a 
means for the arrival of data to ini¬ 
tiate a process. 

5.1 Queues 

A queue is an ordered collection of 
M-spaces, which may be an empty col¬ 
lection. M-spaces in a non-empty 
collection are referred to as items 
of the queue. Queues can be defined 
as part of the definition of a C-pro- 
cess model, or by the DEFINE QUEUE 
instruction (QDEF), and are made 
available in the following way. 

o Each queue is assigned an arbi¬ 
trary 32-bit queue name as part 
of its definition. Queue names 
must be chosen so as to complete¬ 
ly distinguish one queue from an¬ 
other. However, reference to the 
queue in all active queuing in¬ 
structions is by means of a quaua 
indax (q.ix), which is a 32-bit 
identifier assigned by the sys¬ 
tem. The QUEUE INDEX instruction 
CQIX) is used to determine the 
q.ix from the name. 


o A queue defined by a DCPM in¬ 
struction in association with a 
process model of the C-process 
class is called an input quaua 
for the model, and any process of 
the process model family is 
called an attendant process of 
the queue. Items may be entered 
into into an input queue by any 
process irrespective of process 
class, but may be extracted from 
the queue only by an attendant 
process. 

o More than one queue can be asso¬ 
ciated with a given process mod¬ 
el, but a given input queue can 
be associated with only one pro¬ 
cess model. If a process model 
has multiple associated input 
queues, the queues are assigned a 
precedence sequence with respect 
to one another. 

o An input queue serves as a pro¬ 
cess source for the associated 
process model: an item entered 
into the queue when the queue is 
empty automatically triggers a 
request for initiation of a pro¬ 
cess of the family. 

o A queue defined by a QDEF in¬ 
struction becomes a public queus 
, not associated with any process 
model. Items may be entered into 
a public queue by any process it— 
respective of class, and may be 
extracted by any process of the 
C-process class. 

A queue, like a domain, is provided 
with a name in order that it have a 
permanent referent which can be as¬ 
sembled as a constant in storage or 
entered as input data. It is pro¬ 
vided with a q.ix in order to opti¬ 
mize instruction execution 

performance. Except for the value 
zero, which always designates the 
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null queue, queue indices are 
model-dependent and not predictable. 
Consequently, a q.ix cannot safely be 
passed from one process to another. 
In order to assure correct results, 
any process not an attendant of a 
queue must execute a QIX instruction 
before referencing the queue. 

Given a name, the QDEF instruction 
defines a queue of that name and re¬ 
turns its q.ix. If a queue with the 
given name already exists it is not 
redefined; the q.ix is returned with 
a condition code indicating prior ex¬ 
istence. The QIX instruction, on the 
other hand, returns the q.ix of an 
existing queue corresponding to a 
given name, or else an indication 
that no such queue exists. 

Sixteen bytes are withdrawn from the 
M-storage pool for every queue de¬ 
fined, to be used by the system for 
queue control. Queue definition will 
be rejected if M-storage for the con¬ 
trol area is not available. The re¬ 
jection is indicated by the condition 
code set for the DCPM or QDEF 
instruction attempting the defi¬ 
nition. 

5.2 Process Modal Definition 

The information required by a DEFINE 
C-PROCESS MODEL instruction (DCPM) 
is specified by means of a C-process 
Model Definition Block (CMDB). A 
CMDB must begin on a word boundary 
and have the format described in fig¬ 
ure 5.1. 

The DCPM instruction will define a 
new process model, replace an exist¬ 
ing one, or delete a model entirely, 
depending on the content of the CMDB. 

o A new model is defined if there 
is not already one with the name 
specified in field CMNME. If a 
model does exist and if deletion 
is allowed, it will be replaced 
or deleted; if deletion is not 


allowed, the definition attempt 
will be rejected. Replacement 
occurs if field CMINS is 
non-zero, deletion if the field 
is zero. Replacement consists of 
first deleting the existing mod¬ 
el [Section 5.31, followed by de¬ 
finition of the new model. 
Deletion will not occur if the 
definition attempt is rejected 
for any reason. 

o When definition is complete the 
CMDB area is immediately avail¬ 
able for new use, as the process 
model control information is re¬ 
tained by the system in an area 
withdrawn from the B-storage 
pool. Definition will be re¬ 
jected if storage is not avail¬ 
able, and the rejection 
indicated by condition code re¬ 
turn . 

o The definition attempt will also 
be rejected if field CMCID does 
not identify a valid computation 
cycle, if any of the proposed in¬ 
put queue names duplicate the 
name of an input queue for anoth¬ 
er process model, if the proposed 
entry context space is not in 
custody of the defining process, 
or if M-storage is not available 
for queue control areas. 

The remaining fields of the CMDB are 
not examined by the DCPM instruction. 
If they contain information which is 
invalid (e.g. field CMMOD does not 
contain a pointer), or later becomes 
invalid, the error will be noted at 
the time of attempted use, and an 
'invalid process model' system 
exception will then be raised 
[Section 9.51. 

The CMDB of an existing process model 
can be inspected at any time by exe¬ 
cution of a STORE CMDB instruction 
(SCMDB) within any C-process or 
R-process. The data can be used to 
check field validity, to replace or 
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Figure 5.1 

C-process Model Definition Block 


Field Offset Bytes 


Description and Use 


CMMOD 0 4 A pointer to the module space which contains the ini¬ 

tial instruction sequence to be executed by every 
process of the process family. 

CMFLG 4 1 Bits defining conditions of usage for the process 

model and members of the family. 


Bit Value 


Sionificance 


0 


0 

1 


Collect process statistics under control of col¬ 
lection instructions 
Do not collect process statistics 


1 0 

1 

2 0 
1 


The initial value of the domain identifier for pro¬ 
cesses of the family is to be the identifier of the 
entry context space 

The initial value of the domain identifier is that of 
the common domain if a queue acted as source for the 
process, or the domain identifier of the source pro¬ 
cess if initiation is caused by an INIT instruction 

The domain identifier may vary during execution 
The domain identifier is fixed during execution 


3 


0 The entry context space identified by field CMCTX is 

to be bound to the process model 
1 Do not change custody of the entry context space 
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4-6 


1 

Field Offset Bvtes 

CMLOC 5 3 

CMMSK 8 1 

CMINS 9 1 

CMCID 10 1 

CMQNO 11 1 

CMNME 12 4 

CMXMD 16 4 

CMCTX 20 4 

CMRSR 24 4 

CMIQL 28 Var 


Reserved 

7 0 Place this process model in system custody if 

custody is transferred 

Place in public custody on a transfer of custody 
Description and Use 


Base address within the module space identified by 
field CMMOD of the first instruction of the initial 
instruction sequence. 

Value of the exception mask field for initial entry 
to processes of the family. 

An integer specifying the maximum number of family 
members in existence at the same time. If the value 
is between 1 and 254, the maximum is the value; if the 
value is 255, an unlimited number of instances is al¬ 
lowed. A value of zero indicates a deletion request. 

The identifier of the computation cycle with which 
the process model is to be associated. 

An integer whose value specifies the number of input 
queues associated with the process model. 

The name of the model. Process model names are 32-bit 
permanent referents which must be unique within the 
set of process models, but need not differ from names 
in other name sets (e.g. queue names). 

A pointer to the module space which contains the ini¬ 
tial instruction sequence for handling process excep- 
tions. 

A pointer to an ordinary space which becomes the en¬ 
try context for processes of the family. 

Reserved for use as selection routine input data. 

Names of the input queues to be to be associated with 
the process model, listed in order of the precedence 
sequence for queue switching [Section 5.83; the num¬ 
ber of entries in the list is equal to the value of 
field CMQNO. 


delete the model, or simply to detei— 5.3 Process Modal Daletion 

mine the names of the input queues 

associated with the model. C-process models and queues are as¬ 

signed to the custody of some process 
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family for protection against arbi¬ 
trary deletion. 

o A C-process model is assigned to 
the custody of the family of the 
defining process. It can be 
deleted by a DCPM instruction, 
operating in replacement or 
deletion mode, if the instruc¬ 
tion is executed within a custo¬ 
dian process. 

o An input queue is bound to the 
custody of its associated pro¬ 
cess model, and can be deleted 
only as part of the deletion of 
that model. 

o A public queue is assigned to the 
custody of the family of the de¬ 
fining process. It can be de¬ 
lated by a DELETE QUEUE 
instruction (QDEL) executed 
within a custodian process. 

Unlike spaces, the continued exist¬ 
ence of process models and queues is 
not tied to the continued existence 
of their custodian; they are trans¬ 
ferred to alternative custody if 
their initial custodian is itself de¬ 
leted. 

o If bit 7 of field CMFLG of its 
CMDB is zero, a C-process model 
and its associated input queues 
are transferred to bound custody 
of the system. No process can 
then execute a valid DCPM in¬ 
struction for the model, so it 
cannot be deleted or replaced ex¬ 
cept by re-initialization of the 
system. 

o If bit 7 of the field is 1, the 
C-process model and its input 
queues are transferred to public 
custody. Any C-process or R-pro- 
cess can then execute a valid 
DCPM instruction for the model. 
If the DCPM causes the model to 
be replaced, the new model is 
transferred to family custody of 


the defining process. 

o A public queue is always trans¬ 
ferred to public custody. 

When any queue is deleted, spaces 
resident in the queue are also de¬ 
leted, the effect being as if a FREE 
instruction had been issued for each 
space. When a process model is de¬ 
leted, spaces held in family custody 
are deleted, as is the entry context 
space if bit 3 of field CMFLG of the 
CMDB caused the space to be bound to 
the model. The input queues are then 
deleted, followed by deletion of the 
model. However, if deletion is an 
intermediate step in replacement of 
the model, objects bound to the model 
are not deleted if they are to be 
used for the new model. 

o If field CMCTX of the new CMDB 
identifies the entry context 
space already bound to the modal, 
the space remains in existence. 
If, at the same time, bit 3 of 
field CMFLG of the new CMDB indi¬ 
cates that the entry context 
space is not to be bound to the 
model, the space is placed into 
family custody of the replaced 
model. 

o The queue list of the new CMDB is 
compared against the input queue 
list of the existing model and 
queues which appear in both lists 
are not deleted prior to replace¬ 
ment of the model. 

The QDEL and DCPM instructions are 
synchronous to the process within 
which they are executed, so that de¬ 
letion is effective at instruction 
completion. In some models of 
EPSILON systems, however, the 
M-storage and B-storage areas used 
for queue control and CMDB data may 
be retained by the system on instruc¬ 
tion completion, for use in future 
queue and process model definition. 
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5.4 Initiation 

A request for initiation of a C-pro- 
cess is triggered when either 

o an INITIATE PROCESS instruction 
(INIT) is executed specifying a 
defined process model* or 

o an item is placed into an input 
queue which was previously emp¬ 
ty. 

Items are entered into a queue by 
means of the ENQUEUE instruction 
(ENQ), whose operands denote the q.ix 
and the M-space. The INIT instruc¬ 
tion, however, denotes the name of 
the process model, so that INIT is a 
direct request for initiation of a 
process of a particular family, while 
ENQ carries an implicit request for 
initiation of a process to serve a 
particular queue irrespective of as¬ 
sociated process model family. Con¬ 
sequently, ENQ is made available to 
all processes, but INIT can be exe¬ 
cuted only within a process of the 
C-process class. 

The sequence of action necessary to 
convert an initiation request into a 
C-process ready to be dispatched for 
the first time is carried out by 
microcode as a closed function of the 
system. The general principle em¬ 
bodied in the initiation microcode is 
to minimize the length of the initi¬ 
ation sequence without sacrificing 
its transparency. Therefore, even 
though no conditions are imposed on 
tiie residence of the initial instruc¬ 
tions or process modal control data, 
the initiation sequence chosen in any 
particular case will make use of res¬ 
idence conditions generated by pre¬ 
vious activity in the system. The 
general procedure is as follows. 

o When the request is triggered, a 
test is made to see if the pro¬ 
cess model control data is resi¬ 
dent in M-storage. The data will 
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be resident if a process of the 
family exists or is being termi¬ 
nated; it may still be resident 
if a process previously existed. 

o If the data is in M-storage the 
membership status of the family 
is examined. If there are al¬ 
ready as many processes of the 
family in existence as the maxi¬ 
mum specified in field CMINS of 
the CMDB, the request is consid¬ 
ered to be satisfied and no fui— 
ther action is taken. If the 
maximum has not been attained, 
the request becomes an active 
one. In either case, the INIT or 
ENQ instruction which triggered 
the request is then completed 
with condition code zero. 

o If the data is not resident in 
M-storage, a search of B-storage 
is started. An ENQ instruction 
is completed whan the search be¬ 
gins, as the existence of an in¬ 
put queue guarantees the 
existence of an associated pro¬ 
cess model; for the opposite rea¬ 
son, interpretation is suspended 
for an INIT instruction during 
the period of the search. The 
search is carried out in incre¬ 
mental steps at each entry to in¬ 
itiation service by dispatching 
[Section 4.2]. If the search is 
terminated by loading the con¬ 
trol data into M-storage, the re¬ 
quest becomes an active one. If 
there is no CMDB correspond; ng to 
the request, interpretation of 
the associated INIT instruction 
will resume, and it will be com¬ 
pleted with a condition code in¬ 
dicating the request was 
dropped. 

o Active requests are processed 
incrementally by initiation 
service [Section 4.2] until sat¬ 
isfied. If there is a process of 
the family which is in general 
wait condition, the request will 


Chapter 5 


42 


C-Processes 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


be satisfied by placing the pro¬ 
cess into ready condition; oth- 
erwise, an initial state vector 
will be prepared for a new pro¬ 
cess of the family. The state 
vector data resides in M-stoi— 
age, so a new process may not be 
brought into existence until 
storage is available. 

o When the state vector area is 
available, the CMDB fields 
CMMOD, CMLOC, CMXMD, and CMCTX 
are examined for validity. CMMOD 
must identify either the null 
space, or a module space for 
which field CMLOC designates an 
instruction location which lies 
within the space. CMXMD must 
identify either the null space or 
a module space. CMCTX must iden¬ 
tify either the null space or an 
ordinary space. Initiation is 
suppressed with an ’invalid pro¬ 
cess model' system exception 
[Section 9.5] if any of the 
fields is discovered to be inval¬ 
id. 

o If field CMLOC identifies a mod¬ 
ule B-space, the space is exam¬ 
ined to see if an M-space 
descendant generated by a link¬ 
age instruction exists. If one 
does not exist, it is formed by 
executing the equivalent of a 
CALL instruction. 

o If field CMCTX identifies an or¬ 
dinary B-space, and if there are 
no other processes of the family 
in existence, an M-space de¬ 
scendant of the space is formed 
by executing the equivalent of a 
LOAD instruction. The descend¬ 
ant, or the original space if 
field CMCTX identifies an 
M-space, becomes the entry con¬ 
text space for the process. Pro¬ 
cesses of the family can be 
supplied values, pointers, 
names, and other initial data by 
means of the entry context. If 


they are allowed write access to 
the space, it can also be used in 
conjunction with an access con¬ 
trol gate [Section 5.103 to pass 
information between family mem¬ 
bers or generations. 

o The initial state vector is then 
loaded with standard entry data 
and the new process placed in 
ready condit i on. 

Because of the nature of the steps 
taken to initiate a process, the 
elapsed time between a request and 
the existence of a corresponding 
ready process cannot be predicted. 
It is possible to determine an upper 
bound to the time, but only for each 
EPSILON system individually, as the 
bound depends both on the model and 
the application mix. Once a C-pro- 
cess exists, however, its elapsed 
time behavior is governed by its own 
instruction execution during time 
apportioned within its computation 
cycle. 

5.5 State Vector 

The state vector of any process con¬ 
sists of the general registers, a 
Process Instruction Counter (PIC), 
and internal control data, all of 
which reside in M-storage. The 
internal control data is accessible 
only to the microcode, but the PIC 
can be obtained by the LOAD PROCESS 
INSTRUCTION COUNTER instruction 
(LPIC). The PIC is a double-word 
with the format described in figure 
5.2. 

The LPIC instruction loads the PIC of 
the process within which it is exe¬ 
cuted into a specified general regi¬ 
ster of that process. Field PCUR is 
loaded into the pointer register by 
executing the equivalent of an LP in¬ 
struction; fields PFLG and LCUR are 
placed into the arithmetic register. 
LPIC is a modal instruction which can 
also be executed within an R-process 
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PCUR 

PFLG 

LCUR 


Figure 5.2 

Process Instruction Counter 


Field 

Offset 

Bvtes 

Description and Use 

PCUR 

0 

4 

Pointer to the M-space containing the next instruc¬ 
tion to be executed 

PFLG 

4 

1 

Bits defining the condition and status of activity 
for the process 


Bit 

Value 

S i gni ficance 


0 

0 

normal condition for C-process or R-process; indi¬ 
cates D-process has no current space 



1 

process activity is being monitored (C-process); the 
process has been unable to close an access control 
gate (R-process); there is an I/O request space cui— 
rent for the process (D-process) 


1 

0 

normal 



1 

the process has closed a data access gate 


2 

0 

normal 



1 

a process exception is not yet cleared 


3 

0 

normal 



1 

the process is being terminated 


4,5 

1-3 

Length in halfwords of the last instruction executed 


6,7 

0-3 

Current condition code 

Field 

Offset 

Bvtes 

Description and Use 

LCUR 

5 

3 

Base address within the space identifed by field PCUR 


of the next instruction to be executed 


or D-process. As shown in figure 
5.2, the PIC for processes of all 
classes has the same format; content 
is also the same except for the in¬ 
terpretation of bit 1 of field PFLG 
CThe function of the current space of 


a D-process is described in Section 
7.61 . 

5.6 Procass Entry 

When a C-process is dispatched for 
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the first time its state vector is 
loaded with the following initial da¬ 
ta . 

o The PIC contains the location of 
the first instruction to be exe¬ 
cuted, as generated during the 
initiation sequence. Field LCUR 
contains the value of field CMLQC 
of the CMDB; field PCUR desig¬ 
nates the space identified by 
field CMMOD, if it i s an M-space, 
or an M-space descendant, if it 
i s a 8-space. 

o Pointer register zero contains a 

pointer to the entry context 
space generated during the ini¬ 
tiation sequence. The register 
is set up as if it had been 
loaded with an LP instruction. 
Arithmetic register zero con¬ 
tains zero. 

o Pointer register 1 contains the 

null pointer. Arithmetic regi¬ 
ster 1 contains the q.ix of the 
input queue which triggered ini¬ 
tiation, or zero if an INIT in¬ 
struction was the trigger. 

o All other general registers con¬ 

tain zero in the arithmetic regi¬ 
ster field and a null pointer in 
the pointer register field. 

o The exception mask and domain 

identifier are set as specified 
in the process model. 

If field PCUR of the PIC identifies a 
space to which the process does not 
have read access, the process is tei— 
minated immediately and an invalid 
process model system exception is 
raised. If the space is the null 
space, instruction execution is not 
started. All spaces in the input 
queue which triggered initiation, if 
any, are deleted from the system, and 
termination is requested as i f an EX¬ 
IT instruction with an operand value 
of zero had been executed [Section 


5.12]. If the space is not null, in¬ 
struction execution begins with the 
first instruction and continues un¬ 
til a CPU switch occurs, at which 
time interpretation of the instruc¬ 
tion sequence is suspended. If the 
switch was caused by expiration of a 
basic cycle, the state vector will be 
preserved intact, and when the pro¬ 
cess is next dispatched instruction 
execution will resume from the point 
of suspension. CPU switching due to 
computation cycle activity is there¬ 
fore invisible to all processes. 
There are, however, two instructions 
by which a process can explicitly 
return control of its assigned CPU to 
dispatching. 

o The IDLE instruction is used to 
indicate that the process activ¬ 
ity for this computation cycle is 
finished. The process is suspen¬ 
ded in ready condition at in¬ 
struction completion. It will be 
dispatched during the next com¬ 
putation cycle with the state 
vector preserved, except that 
the process instruction counter 
is set to the reentry location 
specified by the operand of the 
IDLE instruction. 

o The WAIT instruction is used to 
indicate that the process must 
wait for some event or occui— 
rence. The process is suspended 
in general wait condition at in¬ 
struction completion. It will 
not be dispatched again until the 
wait is removed by an initiation 
request, or by expiration of the 
maximum wait time specified by 
the operand of the WAIT instruc¬ 
tion. The state vector is pre¬ 
served, so that when the process 
is next dispatched the first in¬ 
struction executed is the one 
following the WAIT. 

Control of the CPU will also be re¬ 
turned by a termination request, but 
the process will not then again be 
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dispatched. 

5.7 Linkage 

Normal system procedure is to execute 
instructions drawn sequentially from 
the same module M-space. After an 
instruction is fetched from the loca¬ 
tion specified by the process in¬ 
struction counter, the address in 
field LOUR is incremented by the num¬ 
ber of bytes of the instruction to 
yield the location of the next in¬ 
struction. If the address becomes 
larger than the extent of the module 
space, it is reduced by the extent, 
so that instruction fetch wraps 
around the space. 

The normal procedure is changed by 
branching and linkage instructions. 
Branching instructions, such as 
BRANCH ON CONDITION or BRANCH AND 
LINK, change the fetch sequence while 
leaving unchanged the space from 
which they are fetched. The branch 
address generated by the instruction 
replaces the the address in field 
LCUR of the PIC, but no action is 
taken to change the space identified 
by field PCUR. The linkage instruc¬ 
tions provide for a change of space 
as well, in order to allow instruc¬ 
tions from more than one module space 
to be executed within the same pro¬ 
cess . 

The CALL instruction, which is a 
modal instruction executable within 
all processes, links to a new space. 
When executed within a C-process or 
D-process = 

o The operand can identify either a 
module B-space or M-space for 
which the process has read 
access. If a B-space is identi¬ 
fied it is examined to see if an 
M-space descendant generated by 
a previous CALL exists. If one 
does not, it is formed by execut¬ 
ing the equivalent of a LOAD in¬ 
struction. The process is placed 


into I/O wait dispatching condi¬ 
tion until the loading is com¬ 
pleted. 

o When the M-space is available, 
either as the original operand or 
as the descendant of a B-space, 
the PIC is saved in a linkage 
control area of the state vector. 
Field LCUR is then set to the 
base address specified by the in¬ 
struction operand, field PCUR is 
set to identify the new M-space, 
and the instruction is com¬ 
pleted. 

When executed within an R-process the 
operand of a CALL must identify an 
M-space or else a specification ex¬ 
ception will occur; the instruction 
behavior is the same in all other re¬ 
spects . 

An M-space allocated by linkage as a 
descendant of a B-space, either dui— 
ing initiation or by a CALL instruc¬ 
tion, is assigned to the .private 
custody of the associated process, 
but its custody flag is not turned 
on. It will be deleted automatically 
by the system when no longer in use, 
or when the process is terminated. 
However, as a consequence of the be¬ 
havior of the linkage mechanism, the 
space may become the source of in¬ 
structions for other processes exe¬ 
cuting concurrently. The reference 
count of the space is therefore in¬ 
cremented by the CALL instruction, so 
that deletion will be delayed, if 
necessary, until the space is not in 
use by any process. 

Similarly, the M-space from which in¬ 
structions were fetched prior to a 
CALL continues to exist, and will 
continue to exist irrespective of 
whether it is in use by other pro¬ 
cesses, until released by action of 
the process within which the CALL was 
executed. Spaces are released either 
by termination of the process or by 
execution of a RETURN instruction. 
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RETURN reverses the CALL procedure, 
releasing the current space as the 
source of instructions for the pro¬ 
cess and restoring the previous 
space. 

o The reference count of the space 
which was released is decre¬ 
mented, so that if it is not in 
use by any other process it will 
be deleted from the system. 

o The PIC is set to the value saved 
from the last CALL instruction 
executed by the process, so that 
normally the next instruction 
fetched will be the one following 
that CALL. If no previous CALL 
was executed, the RETURN is 
treated as an EXIT instruction 
[Section 5.12]. 

o The operand of RETURN specifies 
instruction length and condition 
code bits in the format of field 
PFLG of the PIC. After the PIC 
is restored to its previous val¬ 
ue, field LCUR is incremented by 
the number of half-words indi¬ 
cated by the length code, and the 
instruction is completed by set¬ 
ting the condition code to the 
value specified by the operand. 

CALL and RETURN are paired in the 
manner of stack operations, with CALL 
corresponding to the push and RETURN 
to the pop. The pairing is strictly 
maintained, as there is no instruc¬ 
tion which will do a return linkage 
to a CALL prior to the latest one. A 
process is not, however, required to 
execute as many RETURN instructions 
as CALL instructions. 

5.8 Communication Via Quauas 

Apart from changing the PIC and the 
condition code, the linkage instruc¬ 
tions do not affect the process state 
vector. Hence, data or data loca¬ 
tions can be exchanged between dif¬ 
ferent instruction sequences of a 


single process by means of the genei— 
al registers. However, exchange of 
information between different pro¬ 
cesses requires another mechanism, 
as the registers of a process are 
private to that process. 

Input queues are the principal means 
of exchanging information between 
C-processes. They are also the only 
means by which R-processes and D-pro- 
cesses can transmit data to be acted 
upon by C-processes. The data to be 
exchanged or transmitted is placed 
into an ordinary M-space and an EN¬ 
QUEUE instruction (ENQ) is executed 
specifying the space and the q.ix. 
An attempt to enqueue a module 
M-space or a B-space of any kind will 
be rejected with a specification ex¬ 
cept i on. 

Because a queue is specified rather 
than a process, communication is in¬ 
direct; the enqueuing process, in 
fact, cannot even determine the pro¬ 
cess model family associated with the 
queue. But since ENQ carries an im¬ 
plicit request to initiate an attend¬ 
ant of the queue [Section 5.41, a 
permanent basis of communication can 
be established by assignment of each 
queue as the input mechanism for one 
or more data transformation func¬ 
tions. 

The items in a queue are ordered by 
their sequence of entry, with the 
least recently entered item being the 
top or head item, the most recently 
entered the bottom or tail item. 
Successful execution of an ENQ in¬ 
struction enlarges the designated 
queue so that the referenced M-space 
is the new bottom item, with the pre¬ 
vious bottom item becoming its prede¬ 
cessor. An M-space entered into a 
queue becomes part of the queue. It 
loses addressability as a space, and 
passes out of the custody of the 
enqueuing process or process family 
into bound custody of the queue, 
where it cannot be deleted or reclas- 
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sified by any process. Any attempt 
by a process to load a stored pointer 
to the space into a pointer register 
while the space is in the queue will 
return a ’space not available' condi¬ 
tion code. 

In a manner similar to the action of 
the FREE instruction, and for the 
same reasons [Section 3.4], entry of 
an M-space into a queue is delayed 
until all processes which have gained 
access to the space no longer need to 
reference it. The ENQ instruction 
substitutes a null pointer for any 
pointer to the space in all pointer 
registers of the process executing 
the ENQ, and the reference count is 
decremented for each substitution. 
If the count is not then zero, the 
space is held in abeyance until the 
count becomes zero, at which time its 
custody flag is turned off and it 
will be placed into the queue. The 
ENQ instruction, however, always ap¬ 
pears synchronous to a process. 

Once an attendant process is initi¬ 
ated, it may use the DEQUEUE instruc¬ 
tion (DEQ) to receive the queued data 
items. The position and provenance 
of the item extracted from a queue by 
DEQ can be specified by instruction 
options to be that item 

o nearest to the top of the queue, 
or nearest to the bottom of the 
queue, which 

o has any domain identifier, or has 
the domain identifier currently 
assigned to the process within 
which the instruction is being 
executed. 

A pointer to the extracted item is 
placed into the pointer register des¬ 
ignated by the DEQ instruction, and 
the item returns to normal M-space 
existence. Custody is transferred to 
the dequeuing process or its family, 
according to the value specified by 
the custody option, with the custody 


flag turned on, and with the refei— 
ence count set to the value 1. Ex¬ 
cept for its content and domain 
identifier, which remain unchanged, 
the space then cannot be distin¬ 
guished from one obtained by the pro¬ 
cess using an ALLOC instruction. 

If the queue is empty, the DEQ in¬ 
struction returns a null pointer and 
a condition code indication. The 
process may ignore the empty condi¬ 
tion, request termination, or switch 
to another input queue, if there is 
one. It may also suspend activity 
with a QUEUE WAIT instruction 
(QWAIT), which puts the process into 
the queue wait dispatching condi¬ 
tion. Unlike general wait, which is 
cleared by any initiation trigger, 
queue wait is cleared by entry of an 
item into the specific queue desig¬ 
nated by the instruction. The pro¬ 
cess is dispatched again only when 
that occurs, with the instruction 
following the QWAIT as the next in¬ 
struction to be executed. 

Although any input queue associated 
with the family can be accessed by a 
DEQ instruction, the system recog¬ 
nizes one of the queues as the cur¬ 
rent queue of the process and will 
dequeue from it unless the instruc¬ 
tion specifies otherwise. The cui— 
rent queue is set initially as the 
one which triggered initiation of the 
process, or as the null queue if an 
INIT instruction was the trigger; its 
q.ix is placed into arithmetic regi¬ 
ster 1 at first entry to the process 
[Section 5.61. The QUEUE SWITCH 
instruction (QSWCH) changes the set¬ 
ting of the current queue 

o to the queue which is higher in 
the precedence sequence than all 
other non-empty queues, or 

o to the null queue if all queues 
are empty. 

The q.ix of the new current queue is 
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returned in the arithmetic register 
designated by the instruction. 

The null queue may be specified in 
any instruction which takes a q.ix as 
an operand. It is treated as a queue 
which does not exist or is always 
empty, as appropriate .for the in- 
structi on •’ 

o for ENQ the result is release of 
the space as if a FREE had bean 
executed 

o for QWAIT the wait condition is 
not generated and the instruc¬ 
tion becomes equivalent to an 
IDLE 

o for DEQ the result is the 'queue 
empty' condition code return 

The null queue is useful in writing a 
module to execute without change 
within processes intiated by INIT as 
well as processes intiated by queuing 
of data. 

5.9 Domain Idantification 

The DEQ instruction is the only in¬ 
struction which can cause a change of 
domain identifier for a C-process. 
This leads to the following simple 
rules for assignment of domain iden¬ 
tifier to C-processes. 

o If bit 1 of field CMFLG of the 
CMDB is zero, the initial domain 
identifier is the domain identi¬ 
fier of the entry context space. 
An assignment can always be made, 
as the null space belongs to the 
common domain. 

o If bit 1 of field CMFLG is 1, and 
if an input queue triggered ini¬ 
tiation, the common domain iden¬ 
tifier is assigned to the 
process;*if an INIT instruction 
triggered initiation, the ini¬ 
tial identifier is the one which 
the initiating process had when 


the INIT was executed. 

o If bit 2 of field CMFLG is 1 the 
intial identifier is retained by 
the process throughout its life¬ 
time. If bit 2 is zero, the do¬ 
main identifier is changed by 
execution of a DEQ instruction to 
the domain identifier of the 
space just dequeued; the new do¬ 
main identifier remains current 
until the next dequeue. 

The current domain identifier of a 
process becomes the domain identifi¬ 
er of any ordinary space allocated by 
the process using an ALLOC instruc¬ 
tion [Section 3.53. 

5.10 Shared Data 

Processes can always exchange infoi— 
mation by simply addressing data di¬ 
rectly at a common location. If the 
data is constant or can be updated in 
place by some instruction, any group 
of processes can share the data as 
long as they have access to the space 
of residence. If data update re¬ 
quires more than one instruction, di¬ 
rect access will usually obtain 
invalid data because processes in 
EPSILON systems behave as if they all 
are advancing concurrently. Some ad¬ 
ditional mechanism is required, 
then, if complex data is to be 
shared. 

The mechanism provided, called an 
accass control gate, or simply a 
gate, achieves the desired result by 
assuring that the advancement of a 
group of processes will be mutually 
exclusive in time. A gate is any 
word, located on a word boundary in 
some M-space, which becomes a special 
resource because of reference by 
CLOSE GATE (CLOSE) and OPEN GATE CO- 
PEN) instructions. A gate belongs to 
a process which executes a successful 
CLOSE instruction; it is released by 
a successful OPEN instruction. A 
gate which belongs to some process is 
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said to be Closad, otherwise it is 

opan. 

A CLOSE followed eventually by an 
OPEN referencing the same gate and 
executed by the same process delimits 
the instruction sequence included 
between the matched pair of gating 
instructions as an exclusive se¬ 
quence. A process is guaranteed that 
an instruction sequence delimited by 
a matching pair of gating instruc¬ 
tions will be executed exclusively in 
time relative to any instruction se¬ 
quence of any other process of the 
same process class which is delimited 
by a pair of gating instructions ref¬ 
erencing the same gate. Exclusivity 
is limited to processes of the same 
process class in order to be consist¬ 
ent with normal dispatching activ¬ 
ity, and is not extended to 
D-processes. 

To operate properly, a gate must be 
initialized to a zero value and then 
referenced only by CLOSE and OPEN in¬ 
structions. To use a gate for shai— 
ing data, a group of C-processes or a 
group of R-processes need only asso¬ 
ciate the gate with the data and act 
as follows : 

o the gate is assembled to have a 
zero value or is cleared to zero 
by one of the processes before 
use of the first gating instruc- 
t i on 

o a CLOSE is executed by any pro¬ 
cess prior to accessing the data 

o an OPEN is executed by a process 
as soon as it is through with the 
data. 

A gate need not be restricted in use 
to one process class, though it is 
good practice to do so. If a gate is 
open, it can be closed by any C-pro- 
cess or R-process. Once closed, the 
gate and gating instructions refei— 
ring to it behave modally, as the 


connection between gating and dis¬ 
patching is established when a pro¬ 
cess attempts to close a gate which 
is already closed. If a gate belongs 
to a C-process 1 

o An attempt to close the gate by 

an R-process will be. rejected 
with a condition code indicating 
incorrect process class. 

o An attempt to close the gate by 

another C-process will put that 
process into gate wait dispatch¬ 
ing condition, and an internal 
gate queue will be formed. As 
long as the gate is closed any 
other process which attempts to 
close it will be placed at the 
end of the queue. 

o If there is no gate queue, an 

OPEN instruction simply returns 
the gate to open status. If 
there is a gate queue, then the 
OPEN has the effect of completing 
the CLOSE instruction for the 
process which is at the head of 
the queue. Thus, when the OPEN 
is completed 

the gate belongs to the pro¬ 
cess which was at the head of 
the gate queue 

that process has been re¬ 
moved from the queue and i s 
in ready condition. 

The process within which the OPEN 
was executed is no longer in¬ 
volved with the gate. 

The dispatching treatment accorded a 
C-process in gate wait is determined 
by action of the selection routine 
which services the computation cycle 
of the process. The three standard 
selection routines assign the CPU 
which would have been assigned to a 
process in gate wait to the process 
which owns the gate, thus giving that 
process the CPU time of all processes 
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in the gate queue. This form of dis¬ 
patching promotion has the effect of 
unstacking a gate queue more rapidly 
the longer it becomes. 

If a gate belongs to an R-process: 

o An attempt to close the gate by a 
C-process will be rejected with a 
condition code indicating incoi— 
rect process class. 

o An attempt to close the gate by 
another R-process will result in 
invocation of dispatching to 
suspend the process and switch to 
another. At the same time, the 
process to which the gate belongs 
is temporarily promoted to a dis¬ 
patching priority higher than 
the process just suspended. As 
long as the gate is closed, the 
process to which it belongs con¬ 
tinues to be promoted to a prioi— 
i ty above that of any process 
which attempts to close the gate. 

o If a process has not been pro¬ 

moted, an OPEN instruction sim¬ 
ply returns the gate to open 
status. If the process executing 
the OPEN has been promoted, the 
OPEN returns it to its original 
priority and causes a process 
switch. Normal dispatching ac¬ 
tivity will then assure that the 
highest priority suspended pro¬ 
cess i5 assigned a CPU, and the 
CLOSE instruction which caused 
the suspension is completed when 
the process starts running. 

Although dispatching promotion tech¬ 
niques have a substantial effect on 
the behavior of the system, individ¬ 

ual processes need not take them into 
account as they do not affect the 
functional behavior of the CLOSE and 
OPEN instructions. 

5.11 Deadlock Avoidance 

The OPEN instruction acts like a pro¬ 


cess switch in forcing results of 
previous instructions to be brought 
into physical and conceptual agree¬ 
ment [Section 2.93. Consequently, 
gating is a general means of serial¬ 
izing process execution, which can be 
used for process synchronization as 
well as for resolving resource usage 
conflicts. However, as a process may 
close more than one gate at a time, 
it is possible to create a deadlock 
condition where two or more processes 
block each other's advancement. For 
example, the following two processes 
will very likely create a deadlock: 

Processl Process2 

CLOSE 61 CLOSE G2 

CLOSE G2 CLOSE G1 


OPEN G2 OPEN G1 
OPEN G1 OPEN G2 

Deadlocks can be forestalled by use 
of known avoidance techniques. One 
such technique is to assign a pre¬ 
scribed sequence to a set of gates, 
and to have any process which is to 
close one of the gates first close 
all gates preceding it in the se¬ 
quence. Thus, the following pro¬ 
cesses can never create a deadlock: 

Processl Process2 Process3 

CLOSE G1 CLOSE G1 CLOSE G1 
CLOSE G2 . CLOSE G2 
CLOSE G3 


The system recognizes some potential 
deadlock conditions and will take 
avoidance action or will alert a pro¬ 
cess so it may take action. 

o An attempt by a process to close 
a gate it has already closed or 
to open a gate it has not previ¬ 
ously closed will be rejected 
with a condition code indicating 
the rejection. 
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o An attempt to execute a CLOSE or 
OPEN using a word whose content 
is not consistent with the con¬ 
tent of a gate will be rejected 
with a condition code indicating 
the inconsistency. As an aid in 
the preservation of gates from 
inadvertant destruction, CLOSE 
and OPEN are treated as read in¬ 
structions, even though they al¬ 
ter the gate contents. 
Consequently, a gate can be lo¬ 
cated in a space to which the 
processes which reference it 
have only read access. 

o A C-process will not be placed 
into a gate queue if it is al¬ 
ready holding a gate; the CLOSE 
instruction is rejected with a 
condition code indicating the 
gate is not avilable to the pro¬ 
cess. Recovery action is up to 
the process, as the rejection on¬ 
ly warns against a possibility 
that may never occur. 

o A gate count is maintained for 
each M-space, which is incre¬ 
mented when a CLOSE is executed 
referring to a gate located in 
the space and decremented when an 
OPEN is executed. Any request 
for deletion of the space will be 
held in abeyance until the count 
becomes zero. 

o Deletion of the state vector of a 
terminated process is delayed 
until all gates which belong to 
the process have been opened 
CSection 5.12]. 

If a deadlock does occur for a group 
of C-processes, processes not in¬ 
volved in the deadlock will continue 
to advance normally. The deadlocked 
processes are usually not recovera¬ 
ble. The deadlock may not even be 
detected, except indirectly by sys¬ 
tem behavior. An R-process deadlock, 
however, affects all other pro¬ 
cesses, so provision is made for de¬ 


tecting and breaking R-process 
deadlocks [Section 6.5]. 

5.12 Termination 

A request for termination of a pro¬ 
cess is triggered when either 

o an EXIT instruction is executed 
by the process, or 

o a TERMINATE PROCESS instruction 
(TERM) is executed specifying 
the process modal. 

EXIT can be executed within any pro¬ 
cess to request its own termination. 
The request can signify normal com¬ 
pletion, or recognition of an excep¬ 
tion condition which precludes 
continuation of the process. TERM 
requests termination of all members 
of a process model family currently 
active. The request is accepted if 
executed within any process which is 
allowed to delete the process model, 
otherwise it is rejected with a con¬ 
dition code indication. 

EXIT and TERM are synchronous to the 
process within which they are exe¬ 
cuted; termination is effective at 
instruction completion in the sense 
that the process to be terminated 
will not be dispatched again. Actual 
deletion of the process requires 
recovery of resources still held by 
the process, and is carried out asyn¬ 
chronously by microcode as a closed 
function of the system. For C-pro- 
cesses the steps necessary for de¬ 
letion are processed incrementally 
by C-process termination service. 

o A termination request sets bit 3 
of field PFLG of the PIC to 1. 
When this bit is on, dispatching 
will not assign a CPU to the pro¬ 
cess when it is selected, but 
will substitute termination 
service in its place. 

o If the process has one or more 


Chapter 5 


52 


C-P rocesses 



Principles of Operation 
The EPSILON System 


Vers i on 1.0 
15 June 1976 


I/O requests outstanding, termi¬ 
nation service simply executes 
the equivalent of an IDLE. Idl¬ 
ing will continue each time the 
process is selected until I/O ac¬ 
tivity for the process has 
ceased. 

o When there is no more I/O activ¬ 
ity, termination service deletes 
the spaces which remain in pri¬ 
vate custody of the process. The 
equivalent of one FREE is exe¬ 
cuted at each entry to the pro¬ 
cess until all spaces have been 
released. 

o When all spaces have been de¬ 
leted, the linkage control area 
of the state vector is tested for 
uncompleted linkage sequences. 
The equivalent of one RETURN is 
executed at each entry to the 
process until the linkage stack 
vanishes. 

o At its next entry, termination 
service tests whether the pro¬ 
cess is holding any access con¬ 
trol gates, or is waiting in a 
gate queue. If not, the state 
vector is deleted from M-storage 
and the process disappears from 
the system. 

o If the process is holding a gate 
or is in a gate queue, it will be 
removed from its computation 
cycle but the state vector will 
remain in M-storage. Each time 
after that a CLOSE is executed 
referencing a gate which belongs 
to the process, an OPEN will be 
inserted in front of it. Eventu¬ 
ally all gates belonging to the 
process will be opened; the state 
vector will then be deleted from 
M-storage. 

For purposes of initiation, a termi¬ 
nating process does not count against 
the maximum number of processes al¬ 
lowed the family. If the maximum has 


actually been attained, an initi¬ 
ation request received while termi¬ 
nation is in progress will be held in 
abeyance; it will become active when 
the process is removed from the com- 
putation cycle. 

When the process terminated is the 
only one of its family in existence 
and no initiation request has been 
received, the input queues associ¬ 
ated with the process model are 
primed to trigger initiation re¬ 
quests at first entry of a space 
irrespective of whether or not they 
are empty. A process is therefore 
not required to empty its input 
queues in order to assure continued 
initiation of processes of the fami¬ 
ly. 

5.13 Exception Handling 

The 15 process exceptions are as¬ 
signed exception codes and divided 
into four severity classes, as shown 
in figure 5.3. The treatment of a 
process exception depends upon 
whether or not a non-null exception 
module is currently defined for the 
process. An exception module speci¬ 
fied by a CMDB becomes current for 
all processes of the family as soon 
as they are initiated. A DEFINE EX¬ 
CEPTION MODULE instruction (DXM) can 
then be executed within a C-process 
to define a new current exception 
module. DXM also returns a pointer 
to the old exception module, as an 
aid to those applications which may 
wish to change exception handling 
with 1inkage. 

If a process exception which is not 
maskable, or is not masked, occurs 
within a C-process for which a 
non-null exception module is cui— 
rent, it is treated as follows. 

o If the exception module pointer 
designates a space no longer in 
existence, the current exception 
module for the process is changed 
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to the null module, and an inval- 
i d process model system excep¬ 
tion is raised [Section 9.5]. If 
the space exists, a linkage is 
generated to it exactly as if a 
CALL instruction had been in¬ 
serted between the instruction 
which caused the exception and 
its successor. 

o The PIC in effect at the time of 
the exception is stored in an 
exception record to which the 
process is given read access. An 
exception record is 32 bytes in 
extant and also holds the con¬ 
tents of general registers zero 
and 1, in the format described in 
figure 5.4. 

o The state vector at entry to the 
exception handling sequence is 
set so that 

the new PIC reflects the sim¬ 
ulated CALL, with field PCUR 
containing a pointer to the 
exception module or an 
M-space descendant of it, 
with bit 2 of field PFLG set 
to 1 and bit zero set to ze¬ 
ro, and with field LCUR con¬ 
taining zero as the entry 
base address; the condition 
code is not changed except in 
the case of forced excep- 
ti ons 

pointer register zero con¬ 
tains a null pointer 

arithmetic register zero 
contains the exception code 
in the form of a positive 
fixed-point integer 

general register 1 contains 
the location of the excep¬ 
tion record 

General registers 2 through 15 
remain as they were prior to the 
exception, as does all other 


state vector data which can be 
directly altered by the process 
(e.g. the exception mask). 

The exception handling routine can 
take whatever action deemed desira¬ 
ble to recover from the exception, 
and then will conclude with a RETURN, 
indicating recovery has occurred, or 
a termination request, indicating 
continuation of the process is use¬ 
less. If a RETURN is executed, the 
exception routine must set the state 
vector to the values desired at 
resumption of the normal instruction 
sequence. For this purpose, the ex¬ 
ception mask can be set by the SET 
EXCEPTION MASK instruction (SXM), 
and general registers zero and 1 can 
be restored from the exception re¬ 
cord. The return should take into 
account the time at which the state 
vector data was stored. 

o An instruction which causes a 
class 1 or class 2 exception is 
suppressed before the process 
state vector is altered or data 
in storage is modified. 

o Class 3 and class 4 exceptions 
are raised after the instruction 
is terminated or completed. For 
these exceptions the PIC loca¬ 
tion has been updated and regi¬ 
sters or storage may be modified. 

Consequently, if an exception rou¬ 
tine wishes to bypass retry of an in¬ 
struction which caused a class 1 or 
class 2 exception, the corresponding 
instruction length should be in¬ 
serted into the operand field of the 
RETURN instruction. 

If a process exception occurs when a 
null exception module is current, 
system microcode will take the fol¬ 
lowing standard recovery action: 

o class 1 and class 2 exceptions 
cause an EXIT instruction with 
operand value zero 
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PRO 


8 


4 Content of pointer register zero when the exception 

was raised. 


PR1 12 4 


Content of pointer register 1 whan the exception was 
raised. 


ARO 16 4 


Content of arithmetic register zero when the excep¬ 
tion was raised. 


AR1 20 4 


Content of arithmetic register 1 when the exception 
was raised. 


FRCE 24 8 Record extension containing data pertinent to a 

forced exception [Section 5.14], The field has no 
significance for other exceptions. 


o a class 3 exception is recorded 
if process statistics are being 
accumulated; the process then 
resumes at the instruction fol¬ 
lowing the one which caused the 
exception. 

o class 4 exceptions are ignored. 

An exception routine can execute any 
instruction available to a C-pro- 
cess, including DXM. However, an ex¬ 
ception which occurs while an 

exception routine is the current ac¬ 

tivity of a process (i.e. while bit 2 
of field PFLG of the PIC is set on) 
is treated as if a null exception 
module were current. 

5.14 Forced Exceptions 

A process exception can be forced 
when a monitor trace record is stored 
for a process. Tracing is one of the 
process monitoring mechanisms of 

EPSILON systems which actively probe 
process activity. The action of 

these mechanisms in relation to a 
process is governed by bit zero of 
field PFLG of the PIC. A process 
will be actively monitored only when 
the bit is turned on; if the bit is 
zero, process activity is not probed, 
and no monitor exceptions will be 
forced. The value of the monitor bit 


in the PIC is controlled by the SET 
MONITOR MASKS instruction, which al¬ 
so specifies what is to be monitored 
or traced. This instruction is 
described in Section 10.8, together 
with a description of the process 
monitoring mechanisms. 

A process exception can also be 
forced by execution of a FORCE PRO¬ 
CESS EXCEPTION instruction CFPX) 
within any process. The FPX instruc¬ 
tion is a passive monitoring mech¬ 
anism whose action is not governed by 
the monitor bit of the PIC, but by a 
separate eight-bit field in the state 
vector, called the breakpoint mask. 
When an FPX is encountered, each bit 
of the current breakpoint mask is 
combined with the corresponding bit 
of the mask field of the instruction 
by a logical AND operation. If the 
result is non-zero, an exception is 
forced; if the result is zero, pro¬ 
cess activity continues with the in¬ 
struction following the FPX. The 
breakpoint mask of a process is set 
to zero at initial entry. It can be 
changed by execution of a SET BREAK¬ 
POINT MASK instruction (SBKM). 

An exception record stored as the re¬ 
sult of an FPX contains data in the 
FRCE field [Figure 5.4] in the format 
described in figure 5.5. A monitor 
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trace record has the same format for 
its FRCE field, but the internal 
fields contain quite different data 
[Figure 10.14]. The records are dis¬ 
tinguished from one another by the 
condition code set upon entry to the 


exception module. If the condition 
code is zero, the exception was 
forced by an FPX instruction. If the 
condition code is 1, the exception is 
due to process monitoring. 


FXPT 

BKP 

FXBA 


Figure 5.5 

Extension of Exception Record 
Stored by FPX Instruction 


Field Offset Bytes 


Description and Use 


FXPT 0 4 


Pointer portion of the location generated by the op¬ 
erand of the FPX instruction. 


BKP 


4 1 


Breakpoint conditions which caused the interrupt to 
be forced. 


FXBA 5 3 


Base address portion of the location generated by the 
operand of the FPX instruction. 


5.15 Instruction Descriptions 


DEFINE QUEUE 


QDEF R1,D2(X2,B2) <RX> 

The queue list is scanned for a queue whose name is the same as the con¬ 
tents of the word located by the second operand. If such a queue is found, its 
q.ix is placed into arithmetic register R1 and the instruction is completed 
with condition code 1. 

If no such queue exists, a queue is defined having the given name. The 
queue is made a public queue assigned to the custody of the family of the pro¬ 
cess within which the instruction is being executed. The q.ix of the new 
queue is placed into arithmetic register R1 and the instruction completed with 
condition code zero. 
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Process Class: c 

Condition Code 1 

0 Queue defined 

1 Queue already exists 

2 
3 

Exceptions: None 


QUEUE INDEX 


QIX R1,D2(X2,B2) <RX> 

The queue list is scanned for a queue whose name is the same as the con¬ 
tents of the word located by the second operand. If such a queue is found, its 
q.ix is placed into arithmetic register R1 and the instruction is completed 
with condition coda zero. If no such queue exists, the register is cleared to 
zero and the instruction completed with condition code 1. 

Process Class: C 

Condition Code : 

0 Queue exists 

1 Queue does not exist 

2 

3 

Exceptions: None 


DEFINE C-PROCESS MODEL 


DCPM Dl(Bl) <SI> 

The instruction is suppressed with a specification exception if the opei— 
and does not define a location on a word boundary. If the location is valid, 
the process model list is scanned for a C-procass model whose name matches the 
name stored in field CMNME of the CMDB located by the operand. If no such mod¬ 
el exists, the computation cycle identifier in field CMCID of the proposed 
CMDB is tested for validity. If it is not valid the instruction is terminated 
with condition code 1. 

Field CMQNO is examined for input queue count. If non-zero, the proposed 
names are compared against the the queue list, and if any name duplicates that 
of an existing queue the instruction is terminated with condition code 1. If 
the queue names are not duplicates, field CMCTX is examined for an entry con¬ 
text space pointer. If the pointer is non-null and does not identify an ordi¬ 
nary space in private or family custody of the process within which the 
instruction is being executed, the instruction is terminated with condition 
code 1. An attempt is then made to obtain B-storage for the CMDB data and 
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M-storage for queue control areas. The instruction is terminated with condi¬ 
tion code 3 if storage is not available. 

If storage is available, the input queues are added to the queue list, the 
CMDB information stored in the B-storage area, and the process model assigned 
to the custody of the family of the process within which the instruction is 
being executed. If field CMCTX is non-null, and if bit 3 of field CMFLG is 1, 
the entry context space is removed from its current custody and bound to the 
custody of the process model.. The instruction is then completed with condi- 
tion code zero. 

If a process model exists which matches the name in the proposed CMDB it 
is tested for deletion status. Deletion is allowed if the model is in custody 
of the family of the process within which the instruction is being executed or 
if the model is in public custody. The instruction is terminated with condi¬ 
tion code 2 if deletion is not allowed. 

If field CMINS of the proposed CMDB is zero, the model and its input 

queues are deleted from the system. The entry context space is deleted if in 

bound custody of the modal. A queue is deleted by releasing any spaces in the 
queue, followed by removing the control area from the queue list and returning 
it to the M-storage pool. The model is deleted by terminating all existing 
members of its family, followed by returning the CMDB control area to the 
B-storage pool. The instruction is then completed with condition code zero. 

If field CMINS of the proposed CMDB is non-zero, the list of proposed 

queues is compared against the the input queue list of the existing model. 

Names that match are removed from the proposed list and saved separately. An 
attempt is then made to obtain M-storage for queue control areas for the re¬ 
maining queues, if any. The instruction is terminated with condition code 3 
if storage is not available. 

If storage is available, the existing model and the non-matching input 
queues are deleted from the system. The proposed entry context space is com¬ 
pared to the entry context space of the existing model. If the spaces are not 
the same, and if the space of the existing model is bound to its custody, that 
space is deleted from the system. The proposed space then becomes the entry 
context space; whatever its previous custody, it is bound to the custody of 
the model if bit 3 of field CMFLG is 1, and placed into family custody of the 
model if bit 3 is zero. 

The new input queues are added to the queue list, the CMDB information 
stored in the B-storage area of the previous model, the previously existing 
queues associated with the new model, and the new model is assigned to the 
custody of the family of the process within which the instruction is being ex¬ 
ecuted. The instruction is then completed with condition code zero. 

Process Class: c 

Condition Code: 

0 Model defined or deleted 

1 Invalid CMDB format 

2 Deletion not allowed 

3 Storage not available 

Exceptions= 

Specification 
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STORE CMDB 


SCMDB R1,D2(X2,B2) <RX> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. If the location is yal- 
id, the process model list is scanned for a C-process model whose name matches 
the name contained in arithmetic register R1. If no such name can be found, 
the instruction is terminated with condition code 2. 

If a model exists with the specified name, its CMDB data is stored into 
successive word locations starting at the location defined by the second opei— 
and, up to the number of words required to store the complete CMDB. If storing 
a word would require exceeding the space boundary, the instruction is termi¬ 
nated at that point with condition code 1. It is completed with condition 
code zero if the full CMDB is stored. 

Process Class : C 

Condition Code: 

0 Full CMDB stored 

1 Partial CMDB stored 

2 Process model not found 

3 

Exceptions= 

Specification 


DELETE QUEUE 


QDEL R1 <RR> 

If the contents of arithmetic register R1 are not consistent with a q.ix 
the instruction is suppressed with a specification exception. If the queue 
identified by the q.ix is not a public queue the instruction is terminated 
with condition code 1. If the public queue is not in private or family custody 
of the process within which the the instruction is being executed, or not in 
public custody, the instruction is terminated with condition code 2. Othei— 
wise the queue is deleted from the system, arithmetic register 1 is cleared to 
zero, and the instruction is completed with condition code zero. 
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Process Class: C 

Condition Code: 

0 Queue deleted 

1 Queue not public 

2 Deletion not allowed 

3 

Except ions: 

Specification 
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INITIATE PROCESS 


INIT D1(B1) <SI> 

The process model list is scanned for a C-process model whose name matches 
the name stored in the word located by the operand. The instruction is termi¬ 
nated with condition code 1 if no such model can be found. If a model exists 
the request is accepted and the instruction completed with condition code ze¬ 
ro. Initiation will be carried out by initiation service of dispatching 
[Sect ion 5.41. 

Process Class: C 

Condition Code: 

0 Request accepted 

1 Process model not found 

2 

3 


Exceptions: None 


LOAD PROCESS INSTRUCTION COUNTER 


LPIC R2 <RR> 

The PIC of the process within which the instruction is being executed is 
loaded into general register R2. Field PCUR is loaded into the pointer regi¬ 
ster with the same effect as if loaded with an LP instruction [q.v. Section 
3.7] except that the condition code is not set to reflect pointer availabili¬ 
ty, and the combined content of fields PFLG and LCUR is placed into the arith- 
metic registar. 

The instruction is then completed by setting the condition code to indi¬ 
cate the type of PIC stored. 
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Process Class: C,R,D 
Modal 


Condition Code: 

0 C-process class 

1 R-process class 

2 D-process class 

3 

Exceptions 1 None 


IDLE 


IDLE M1,R2 <RR> 

The contents of arithmetic register R2 replace the base address in field 
LCUR of the PIC, and the value of bits 2 and 3 of mask field Ml replace the 
condition code in field PFLG. Control of the CPU assigned to the process is 
then returned to dispatching. The process will begin execution at the new lo¬ 
cation with the new condition coda when next dispatched. 

Process Class: C 

Condition Code: Set by instruction operand 

Exceptions: None 


WAIT 


WAIT R1,R2 <RR> 

The contents of arithmetic register R2 replace the base address in field 
LCUR of the PIC, the process is placed into general wait dispatching condi¬ 
tion, and control of the CPU assigned to the process is returned to di spatch- 
i ng. 

The contents of arithmetic register R1 are interpreted as a 32-bit posi¬ 
tive integer specifying the maximum number of computation cycles the wait is 
to be in effect. The count is decremented by 1 for each cycle following the 
instruction, and the process will be placed into ready condition when the 
count goes to zero if an initiation request has not occurred prior to that 
time. When next dispatched, the process will begin execution at the new in¬ 
struction location with register R1 containing the count current when the pro¬ 
cess was placed into ready condition. 

Process Class-' C 

Condition Code: Unchanged 

Exceptions: None 
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CALL 


CALL M1,R2 <RR> 

If the space identified by pointer register R2 is not a module space the 
instruction is suppressed with a data exception. It is suppressed with an ac¬ 
cess exception if the process does not have read access to the space. If the 
space is a B-space and the instruction is being executed within an R-process, 
the instruction is suppressed with a specification exception. 

If the space is a B-space it is tested for an existing M-space descendant. 
If none exists, the C-process is placed into I/O wait dispatching condition 
and the equivalent of a LOAD instruction is inserted in front of the CALL. The 
I/O wait is removed after the loading is complete and the CALL interpretation 
restored. The new M-space is placed in the private custody of the process 
within which the instruction is being executed. 

Tine process instruction counter is saved in the linkage control area of 
the state vector. The contents of general register R2 then replace the in¬ 
struction counter, bits 2 and 3 of mask field Ml replace the condition code, 
and the instruction is completed by incrementing the reference count of the 
space identified in the instruction counter by 1. 

Instruction execution for the process resumes at the new location with the 
new condition code. 

Process Class: C,R,D 
Modal 

Condition Code: Set by instruction operand 

Except ions: 

Access 

Specification 

Data 


RETURN 


RETURN M2 <RR> 

The linkage control area is examined for a previous CALL executed within 
the process. If none exists the instruction is interpreted as an EXIT in- 
struction. 

If a previous CALL was executed, and if the process has private custody of 
the M-space from which the RETURN was fetched, the space is released from cus¬ 
tody of the process. The reference count of the space is decremented by 1, and 
if the count becomes zero a deletion request is made for the space. 

The PIC saved from the last CALL executed is cleared from the linkage con¬ 
trol area and becomes the new PIC of the process. Field LCUR of the PIC is 
then incremented by the number of half-words specified by the value of the 
field consisting of bits zero and 1 of the operand M2, bits 2 and 3 of the op¬ 
erand replace the condition code, and the instruction is completed. 
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Instruction execution for the process resumes at the instruction speci¬ 
fied by the updated PIC, with the new condition code. 

Process Class 1 C,R,D 

Condition Code : Set by instruction operand 
Exceptions 1 None 


ENQUEUE 


ENQ R1,R2 <RR> 

The instruction is suppressed with a specification exception if the con¬ 
tents of arithmetic register R1 are not consistent with a q.ix. It is sup¬ 
pressed with a data exception if pointer register R2 does not identify an 
ordinary M-space or if the space is in I/O request state, and with an access 
exception if the space is not in private or family custody of the process 
within which the instruction is being executed. 

A null pointer is loaded into pointer register R2 and into any other 
pointer register of the process which contains a pointer to the space, and the 
reference count is decremented by 1 for each pointer loaded. If the reference 
count does not become zero, the space is placed in system custody, the enqueue 
request is recorded, and the instruction is completed with condition code 1. 
The enqueue will be carried out whenever the reference count subsequently be¬ 
comes zero. 

If the reference count is zero, the custody flag is turned off and the 
M-space is placed at the bottom of the queue, bound to its custody. If the 
queue is an input queue and was previously empty, an initiation request is 
triggered designating the process model associated with the queue. If the 
queue is the null queue, the space is released with the equivalent of a FREE 
instruction. The instruction is then completed with condition code zero. 

Process Class: C,R,D 

Condition Code 1 

0 Space enqueued 

1 Enqueuing delayed 

2 

3 

Exceptions : 

Access 

Specification 

Data 
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DEQUEUE 


DEQ M1,R2 <RR> 

If the high order bit of the mask field Ml is zero, the indicated queue is 
the current queue of the process, otherwise the q.ix is to be found in arith¬ 
metic register R2. In that case, the instruction is suppressed with a spec¬ 
ification exception if the contents of the arithmetic register do not specify 
the q.ix of a queue associated with the process. 

If the queue is empty or if the indicated queue is the null queue, pointer 
register R2 is set to the null pointer and the instruction is completed with 
condition code 1. If the queue is not empty, bit 1 of mask field Ml is exam¬ 
ined to determine the domain identifier of the item to be removed from the 
queue. If the bit is zero, any domain identifier is acceptable; if the bit is 
1, the item is to have a domain identifier which matches the identifier of the 
process within which the instruction is being executed. 

Bit 2 of mask field Ml determines the direction of search. If the bit is 
zero, the item is to be extracted as near to the top of the queue as possible; 
if the bit is 1, it is to be extracted as near to the bottom as possible. 
Hence, if bit 1 is zero and bit 2 is also zero, the top item of the queue is 
removed, while if bit 1 is zero and bit 2 is 1, the bottom item is removed. 

If bit 1 is 1, a search of the queue is conducted, starting at the top if 

bit 2 is zero and at the bottom if bit 2 is 1. The first item found with the 

proper domain identifier is removed from the queue. If no such item can be 
found the instruction is terminated with. condition code 2. 

The low order bit of mask field Ml is examined to determine the protection 
vector to be assigned to the space removed from the queue. If the bit is zero 
the space is placed in private custody of the process, with private read and 
write access; if the bit is 1, the space is placed into family custody, with 

family read and write access. The custody flag is then turned on, the refei— 

ence count is set to 1, and a pointer to the space is loaded into pointer regi¬ 
ster R2. 

Bit 2 of field CMFLG of the CMDB for the process model family is examined 
to determine treatment of the domain identifier of the process. If the bit is 
zero, the identifier of the process is replaced by that of the space just de¬ 
queued. If the bit is 1 the identifier is not replaced. The instruction is 
then completed with condition code zero. 

Process Class 1 C 

Condition Code: 

0 Space dequeued 

1 Queue empty 

2 Space not found 

3 

Except ions: 

Specification 
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QUEUE SWITCH 


QSWCH R2 <RR> 

The input queues of the process model for the process are examined to find 
the queue of highest precedence which is non-empty. That queue becomes the 
current queue of the process and its q.ix replaces the contents of arithmetic 
register R2. If there are no input queues for the process or if all queues are 
empty, the null queue becomes the current queue. 

Process Class 1 C 

Condition Code: Unchanged 

Exceptions: None 


QUEUE WAIT 


QWAIT R2 <RR> 

The instruction is suppressed with a specification exception if the con¬ 
tents of arithmetic register R2 do not specify the q.ix of a queue associated 
with the process. 

If the queue is non-empty the instruction is immediately completed. If 
the queue is the null queue, the instruction is interpreted as an IDLE in¬ 
struction. If the queue is empty, the process is placed into queue wait dis¬ 
patching condition and the CPU assigned to the process returned to 
dispatching. The process will be placed into ready condition when an item is 
entered into the specified queue. 

Process Class: c 

Condition Code: Unchanged 

Exceptions: 

Specification 


CLOSE GATE 


CLOSE D1(B1) <SI> 

The gate located by the operand address is made to belong to the process 
within which the instruction is being executed. 

The instruction is suppressed with a specification exception if the gate 
is not on a word boundary. The instruction is terminated with condition code 
3 if the content of the word is not consistent with that of a gate, and with 
condition code 1 if the gate already belongs to the process. 
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If the gate is open, it is closed and assigned to the process. The gate 
count in the space in which the gate is located is incremented by 1, and the 
instruction is completed with condition code zero. If the gate is closed and 
belongs to a process of a different process class than the requeusting pro¬ 
cess, the instruction is terminated with condition code 2. 

If the gate is closed and the requesting process is a C-process, the pro¬ 
cess is placed at the end of the queue of processes waiting for the gate. The 
PIC is reset to the CLOSE instruction, the process is placed into gate wait 
dispatching condition, and the CPU assigned to the process is returned to dis¬ 
patching. The gate wait will be removed by some subsequent OPEN instruction, 
and the process will again request the gate when next dispatched. 

If the gate is closed and the requesting process is an R-process, the pro¬ 
cess to which the gate belongs is promoted to a dispatching priority frac¬ 
tionally higher than that of the requesting process. The PIC of the 
requesting process is reset to the CLOSE instruction, the process is suspen¬ 
ded, and the CPU assigned to the process is returned to dispatching. The pro¬ 
cess will again request the gate when next dispatched. 

Process Class: c,R 

Modal 


Condition Code: 

0 Gate closed 

1 Gate already owned 

2 Gate not available 

3 Invalid gate format 

Exceptions: 

Specification 


OPEN GATE 


OPEN Dl(Bl) <SI> 

The gate located by the operand address is released by the process. 

The instruction is suppressed with a specification exception if the gate 
is not on a word boundary. The instruction is terminated with conditiion code 
3 if the content of the word is not consistent with that of a gate, with condi¬ 
tion code 2 if the gate is open, and with condition code 1 if the gate does not 
belong to the process. 

The closed gate is opened and the gate count in the space in which it is 
located is decremented by 1. If the process is a C-process and there is a gate 
queue, the process at the head of the queue is removed from the queue and taken 
out of gate wait. The instruction is then completed with condition code zero. 

If the process is an R-process which has not been promoted, the instruc¬ 
tion is completed with condition code zero. If the process has been promoted 
it is reduced to its normal priority, suspended, and the CPU assigned to the 
process is returned to dispatching. The instruction will be completed with 
condition code zero when the process is next dispatched. 
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Modal 
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Condition Code: 

0 Gate opened 

1 Gate not owned 

2 Gate already open 

3 Invalid gate format 

Exceptions : 

Specification 


EXIT 


EXIT I <RR> 

Termination is requested for the process within which the instruction is 
being executed. Bit 3 of field PFLG of the PIC is set to 1, the byte of imme¬ 
diate data in the I field of the instruction is saved in the state vector, and 
the instruction is completed by returning the CPU assigned to the process to 
dispatching. 

Termination is completed at some later time by system microcode. 

Process Class: c,R 

Condition Code 1 Unchanged 

Exceptions: None 


TERMINATE PROCESS 


TERM Dl(B1)»12 <SI> 

The process model list is scanned for a process model whose name matches 
the name stored in the word located by the first operand. If no such model can 
be found the instruction is terminated with condition code 1. If the process 
model is not in custody of the family of the process within which the instruc¬ 
tion is being executed, or is not in public custody, the instruction is termi¬ 
nated with condition code 2. 

Termination is requested for all processes of the family currently in ex¬ 
istence. The equivalent of an EXIT instruction with operand field 12 is exe¬ 
cuted for each process, and the instruction is completed with condition code 
zero. 

Termination is completed at some later time by system microcode. 
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Process Class 1 C,R 

Condition Code: 

0 Request accepted 

1 Process model not found 

2 Termination not allowed 

3 

Exceptions: None 


Principles of Operation- 
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DEFINE EXCEPTION MODULE 


DXM R1,R2 <RR> 

The instruction is suppressed with an access exception if pointer register 
R2 does not identify a module space for which the process has read access. 

If the instruction is not suppressed, a pointer to the current exception 
module of the process is placed into arithmetic register Rl, and the instruc¬ 
tion is completed by setting the current exception module to be the space 
identified by pointer register R2. 

Process Class: c 

Condition Code: Unchanged 

Exceptions : 

Access 


SET EXCEPTION MASK 


SXM D1(B1),I2 <SI> 

The current exception mask of the process within which the instruction is 
being executed is stored at the location specified by the first operand. The 
mask is then set equal to the byte of immediate data in the second operand 
field. 

Process Class: c,R 
Condition Code: Unchanged 
Exceptions 1 None 
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SET BREAKPOINT MASK 


SBKM D1(B1),IZ <SI> 

The current breakpoint mask of the process within which the instruction is 
being executed is stored at the location specified by the first operand. The 
mask is then set equal to the byte of immediate data in the second operand 
field. 

Process Class: C,R,D 
Condition Code: Unchanged 
Exceptions: None 


FORCE PROCESS EXCEPTION 


FPX D1(B1),I2 <SI> 

The breakpoint mask of the process within which the instruction is being 
executed is combined with the byte of immediate data in the second operand 12 
using a logical AND operation. If the result is zero, the instruction is tei— 
minated without further action. 

If the result is non-zero, a forced exception record is generated, with 
the result of the logical and operation stored in the BKP field of the record 
extension [Figure 5.51. The pointer portion of the location generated by the 
first operand is stored in field FXPT of the record extension, and the base 
address portion of the location is stored in field FXBA. The instruction is 
then completed by raising a forced exception. 

Process Class 1 C,R,D 

Condition Code: Unchanged 

Exceptions: Forced by instruction execution 
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6.0 R-PROCESSES: EVENT RESPONSE 

Because R-processes are viewed as 
primarily event response activities 
and presumed to have a limited life¬ 
time, they are not provided as much 
arithmetic capability as C-pro- 
cesses. Moreover, restrictions are 
imposed for linkage, data access, 
communication, and in the interpre¬ 
tation of modal instructions that de¬ 
ny to R-processes those functions, 
such as waiting and dequeuing, which 
imply unpredictable instruction exe¬ 
cution time. The objective of these 
restrictions is to assure that in¬ 
struction execution within R-pro- 
cesses will not itself be a source of 
response delay. 

6.1 Process sources 

For any EPSILON system there are 
three kinds of sources for R-pro¬ 
cesses: 

o system services 

time-of-day clock 
system exceptions 

o external signals 

o I/O devices. 

Every source is assigned a dispatch¬ 
ing priority [Section 4.61 and a 
16-bit identifier as part of the 
specification of a system, either at 
the factory or during installation of 
the source in the field. A source 
identifier may have any value except 
zero, which is reserved as a null 
designation; if the source is an I/O 
device its source identifier must be 
the same as its I/O device identifier 
[Section 7.1]. Apart from these re¬ 
strictions, the assignment of prioi— 
i ty and identifiers is arbitrary. 
The assignment can be modified at 
system initialization, but cannot be 
modified by instruction execution. 


The event represented by each source 
is also set up as part of system 
specification. Except for the system 
services, which are fixed sources, 
any signal from the external signal 
interface, or any combination of ex¬ 
ternal and I/O device signals which 
meet the physical configuration con¬ 
straints of a given EPSILON system 
model can serve as a source. Pro¬ 
cesses which are initiated as a re¬ 
sult of signals from a source then 
determine the meaning and signif¬ 
icance of the events represented by 
the source. 

The identifiers of all process 
sources on a given system can be ob¬ 
tained by executing the STORE SOURCE 
LIST instruction (SSL), which stores 
source identifiers in successive 
half-word locations. The number of 
half-words to be stored is specified 
in the SSL instruction, and a count 
of the number of identifiers not 
stored is returned at instruction 
completion. The identifiers are 
stored in order of decreasing dis¬ 
patching priority, starting with the 
source of highest priority. 

6.2 Process Modal Connection 

An event can cause process initiation 
only if a process model is connected 
to its associated process source. 
System service sources are connected 
to built-in process models; however, 
each model requires some additional 
information in order to be complete. 
In some cases the information is sup¬ 
plied using specific instructions 
(e.g. timing event requests), in oth¬ 
er cases it is supplied at system in¬ 
itialization. All other sources are 
connected by means of the CONNECT 
R-PROCESS MODEL instruction (CRPM), 
or the CONNECT R-PROCESS MODEL INDI¬ 
RECT instruction (CRPMI). 
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The data for these instructions is 
supplied by an R-process Model Defi¬ 
nition Block (RMDB). An RMDB must 
begin on a word boundary and have the 
format described in figure 6.1. The 
CRPM and CRPMI instructions can be 
executed only within an R-process; 
they will connect a new process mod¬ 
el, replace an existing one, or de¬ 
lete a model entirely, depending on 
the content of the RMDB. For the 
CRPM instruction, 

o A new model i s connected i f there 
is not already one connected to 
the specified source. If a model 
is connected and if deletion is 
allowed, it will be replaced or 
deleted; if deletion is not al¬ 
lowed, the connection attempt 
will be rejected. Replacement 
occurs if bit 6 of field RMFLG is 
zero, deletion if the bit is 1. 
Replacement consists of delating 
the existing model, followed by 
connection of the new model. De¬ 
letion will not occur if the con¬ 
nection attempt is rejected for 
any reason. 

o When connection is complete the 
RMDB area is immediately avail¬ 
able for new use, as the process 
model control information is re¬ 
tained by the system in an area 
withdrawn from the M-storage 
pool. The area may be reserved 
at system initialization; if it 
is not reserved, connection will 
be rejected if storage is not 
available, and the rejection 
indicated by condition code re¬ 
turn . 

o The connection attempt will also 
be rejected if any of the fields 
RMMOD, RMLOC, RMXMD, or RMCTX are 
invalid. Field RMMOD must con¬ 
tain either a null pointer or a 
pointer to a module M-space for 
which field RMLOC designates an 
instruction location which lies 
within the space. Field RMXMD 


must identify either the null 
space or a module M-space. The 
first four bytes of field RMCTX 
must contain either a null point¬ 
er or a pointer to an ordinary 
M-space in private or family cus¬ 
tody of the defining process. 

o CRPM is synchronous to the pro¬ 
cess within which it is executed, 
so that connection or deletion is 
effective at instruction com¬ 
pletion. 

An R-process model is assigned to the 
custody of the family of the defining 
process. If the custodian family is 
deleted from the system the model is 
transferred to bound custody of the 
system, or to public custody, accord¬ 
ing to the value of bit 7 of field 
RMFLG of its RMDB. It can then be 
deleted or replaced by execution of a 
CRPM or CRPMI instruction only if in 
public custody. 

When an R-process model is deleted, 
spaces held in family custody are de¬ 
leted with it, as is the entry con¬ 
text space if it is bound to the 
model. However, if deletion is an 
intermediate step in replacement of 
the model, and if the entry context 
space for the new model is the same 
as that of the old, the space remains 
in existence. Its custody is then 
determined by the value of bit 3 of 
field RMFLG of the new RMDB. For any 
deletion sequence, existing pro¬ 
cesses of the family are not deleted, 
but will continue activity until tei— 
ininated by standard termination pro¬ 
cedures. The M-storage area used for 
process model control data will be 
retained by the system for future 
use, rather than be returned to the 
M-storage pool. 

CRPMI behaves in the same way as 
CRPM, except that 

o the RMDB data is obtained from 
another process source rather 
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Field 

RMMOD 

RMFLG 


RMMOD 


RMFLG 


RMLOC 


RMMSK 


RMENT 


RMXMD 


RMCTX 


Figure 6.1 

R-process Model Definition Block 


Offset Bytes 


Description and Use 


0 4 A pointer to the module M-space containing the ini¬ 

tial instruction sequence to be executed by every 
process of the process family. 

4 1 Bits defining conditions of usage for the process 

model and members of the family. 


Bit Value 


Si gnificance 


0 


0 

1 


Collect process statistics under control of col¬ 
lection instructions 
Do not collect process statistics 


1 0 The value of the domain identifier for processes of 

the family is to be the identifier of the entry con¬ 
text space 

1 The value of the domain identifier is to be derived 

from the process which triggered initiation if it was 
caused by process action, otherwise it is to be the 
identifier of the entry context space 


2 


Reserved 


3 


0 

1 


The entry context space identified within field RMCTX 

is to be bound to the process model 

Do not change custody of the entry context space 


4 


Reserved 


5 


0 

1 


This is a single-instance process model 
This is a multi-instance process model 


6 


0 Normal 

1 This process model is to be deleted (is indirectly 

connected) 
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7 


0 

1 


Place this process model in system custody if custody 
is transferred 

Place in public custody on a transfer of custody 


Field Offset Bvtes 


Description and Use 


RMLOC 5 3 Base address within the module space identified by 

field RMMOD of the first instruction of the initial 
instruction sequence. 


RMMSK 8 1 


Value of the exception mask field for initial entry 
to processes of the family. 


RMENT 9 3 Communication data supplied to processes of the fami¬ 

ly initiated by a source event. 

RMXMD 12 4 A pointer to the module M-space containing the ini¬ 

tial instruction sequence for handling process excep¬ 
tions. 


RMCTX 16 8 


Entry context data for processes of the family. 


than from a location in some 
M-space 

o if the instruction results in a 
model being connected to the 
source, only the fact of indirect 
connection is maintained; the 
RMDB resides with the referenced 
source, or with the source which 
was directly connected if there 
is an indirect connection chain. 

The CRPMI instruction is useful when 
one model is to be connected to se¬ 
veral sources, as a change to the 
model of the directly connected 
source is effective for all sources 
indirectly connected to it; more¬ 
over, the process requesting the con¬ 
nection is not required to know the 
content of the RMDB. However, when 
specific process model conditions 
are required for a source, a process 
can execute the STORE SOURCE STATUS 
instruction CSRCE) to find out if a 
process model is connected to it. If 
it is connected, the instruction will 
supply the RMDB of the connected mod¬ 
el; when the RMDB is stored, indirect 


connection is indicated by turning on 
the deletion bit of field RMFLG. The 
stored information can be used to 
prepare changes to the process modal 
data. 

6.3 Initiation 

If a process model is connected to a 
source, a request for initiation of 
an R-process is triggered when either 

o an event represented by the 

source occurs, or 

o a SIGNAL SOURCE instruction 

(SGS) is executed specifying the 
source. 

If there are no processes of the fam¬ 
ily in existence, or if processes ex¬ 
ist but the source is not pending, 
the request causes the source to be¬ 
come pending, and initiation of a 
member of the family of the connected 
process model will take place as soon 
as a CPU is available for it to be 
dispatched [Section 4.6], provided 
the M-space specified in field RMMOD 
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of the RMDB is still in existence. 
If the M-space has been freed, initi¬ 
ation will be suppressed and an in¬ 
valid process model system exception 
will be raised. If the source is 
pending, treatment of the request de¬ 
pends on its provenance. 

o If the signal is from the source, 
and if there already is a previ¬ 
ous source signal waiting to 
become affective, the request is 
considered to be satisfied and no 
further action will be taken. If 
there is no previous source 
signal waiting, the request is 
accepted. 

o If the signal is from SG5, and if 
the operand pointer register 
identifies the null space, the 
signal is treated as if it had 
come from the process source. 

o If the operand of an SGS identi¬ 
fies an ordinary space in custody 
of the requesting process, the 
request i s accepted no matter how 
many other signals are waiting to 
become effective. The space is 
removed from custody of the 
requesting process, and becomes 
the communication space given to 
the process initiated as a result 
of the request. 

When a request becomes effective, the 
initial state vector is loaded with 
the following standard entry data. 

o The PIC contains the location of 
tbe first instruction to be exe¬ 
cuted. Field ICUR contains the 
value of field RMLOC of the RMDB, 
and field PCUR contains a pointer 
to the space identified by field 
RMMOD. 

o The condition code is zero if the 
process was initiated because of 
a process source event, and 1 if 
initiation was due to an SGS in¬ 
struct i on. 


o Pointer register zero contains 

the entry context space pointer 
obtained from the first four 
bytes of field RMCTX; the regi¬ 
ster is set up as if it had been 
loaded with an LP instruction. 
Arithmetic register zero con¬ 
tains entry context data ob¬ 
tained from the last four bytes 
of field RMCTX. 

o Arithmetic register 1 contains 

the identifier of the process 
source which triggered initi¬ 
ation. Pointer register 1 con¬ 
tains a null pointer. 

o General register 2 contains the 

communication data. If the con¬ 
dition code is zero, pointer reg- 
ister 2 contains a null pointer, 
and arithmetic register 2 con¬ 
tains the information supplied 
in field RMENT of the RMDB or 
contained in the arithmetic reg¬ 
ister of the operand of an SGS. 
If the condition coda is 1, gen¬ 
eral register 2 contains the full 
communication space pointer and 
data location submitted with the 
SGS instruction, divided between 
arithmetic and pointer registers 
as if directly transmitted from 
the general register referenced 
in the instruction. The pointer 
register is set up as if it had 
been loaded by an LP instruction. 
The space has been transferred to 
private custody of the process, 
with its reference count set to 
1 . 

o All other general registers con¬ 

tain zero in the arithmetic regi¬ 
ster field and a null pointer in 
the pointer register field. 

o The exception mask and domain 

identifier are set as specified 
in the process model. If bit 1 
of field RMFLG of the RMDB is 1, 
and if the condition code on en- 
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try is also 1, the domain identi¬ 
fier of the process is that of 
the communication space; in all 
other cases, the identifier is 
that of the entry context space. 
The domain identifier of and 
R-process remains constant 
throughout the lifetime of the 
process. 

If field POUR of the PIC identifies a 
space to which the process does not 
have read access, the process is 
immediately terminated and an inval¬ 
id process model system exception is 
raised. If the space is the null 
space, execution is not started. The 
communication space, if any, is de¬ 
leted from the system, and termi¬ 
nation is requested as if an EXIT 
instruction with operand value zero 
had been executed. If the space is 
not null, instruction execution be¬ 
gins with the instruction located by 
the PIC and continues until the pro¬ 
cess completes activity. 

6.4 Process Communication 

An R-process need not conform to the 
system view of R-processes as event 
response activities of relatively 
short duration, either as a condition 
of existence or as a means to achieve 
optimal performance. It may well be 
better to complete all activity con¬ 
nected with some class of events 
within the process which is responsi¬ 
ble for the initial response to those 
events. R-processes are therefore 
provided with many of the facilities 
of C-processes, and with a substan¬ 
tial amount of basic computational 
capabi1ity. 

In general, however, it is advanta¬ 
geous to separate initial response 
from subsequent computation, partic¬ 
ularly when time-constraint criteria 
are difficult to establish or subject 
to change. In such a separation, the 
response period is usually short com¬ 
pared to the computation period, and 
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is confined to activity on data imme¬ 
diately available with the event. 
Consequently, once an R-process is 
assigned a CPU and starts running, 
instruction interpretation continues 
without time-slicing or explicit 
waiting periods until terminated by 
an EXIT or TERM instruction. The CPU 
may be switched to a process of high¬ 
er dispatching priority, but if so 
the switch is a temporary expedient, 
and a CPU will be re-assigned to the 
process as soon as possible [Section 
4.6]. Moreover, a CPU switch of this 
kind is invisible to the process; the 
state vector is preserved intact, and 
instruction execution will resume 
without break from the point of sus- 
pension. 

The absence of time-slicing and ex¬ 
plicit waiting capability leads to an 
instruction execution environment 
for R-processes which is quite dif¬ 
ferent than that for C-processes. 
This difference is reflected in the 
way system functions behave with re¬ 
spect to R-processes, and in the in- 
terpretation of modal instructions 
relating to these functions (e.g. 
SAVE, LOAD, CALL). The effect is 
perhaps most noticeable in the area 
of process communication and syn- 
chronization. 

o An R-process can send a message 
to another R-process by placing 
the data to be transmitted into 
some space and executing an SGS 
instruction specifying the 
source of the receiving process. 
The location of the message data 
is specified by the communi¬ 
cation data sent with the SGS, or 
is obtained through some pointer 
chain anchored by the communi¬ 
cation data. 

o Because a process source is spec¬ 
ified rather than a process, com¬ 
munication is indirect; the 
semantics imply that the sending 
process invokes the function 
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associated with the source, and 
that function may be carried out 
by any process of the family. In 
this respect, communication is 
similar to the use of queues by 
C-processes. 

o In contrast to C-processes, 
R-processes cannot expect to ex¬ 
change a sequence of messages on 
a continuing basis. SGS always 
results in the eventual initi¬ 
ation of a new process to receive 
the data. Moreover, there is no 
assurance the new process will be 
initiated unless the sending 
process terminates; for if it 
does not, and if there are fewer 
CPU in the system than R-pro- 
cesses sending messages, initi¬ 
ation cannot occur for the 
process source of lowest priori¬ 
ty involved in the message ex¬ 
change [Section 4.61. 

o Exchange of data between R-pro- 
cesses must therefore be ai— 
ranged to proceed as in a relay, 
with a new process taking up the 
baton at each stage. One method 
to assure continuity in such an 
arrangement is for the processes 
to use a control block interpre¬ 
tation discipline, in which 

the sending process places 
its source identifier and 
re-entry point in a control 
block associated with the 
message, and terminates af¬ 
ter executing the SGS 

the receiving process sends 
a return SGS to the source 
identified in the control 
block, and terminates after 
completing its work 

the new process of the ori¬ 
ginal source executes a CALL 
to the re-entry location 
specified in the control 
block. 


While this method is generally 
applicable, specialized relay 
methods are equally effective, 
and may well be better for a par¬ 
ticular application. 

An R-process will use the ENQ in¬ 
struction to send data to a C-process 
when computational activity for an 
event is to begin. In principle, the 
C-process could use SGS to invoke an 
R-process for some of the computa¬ 
tion, but such usage is dubious. It 
is likely to fail in practice through 
lack of data integrity, as an access 
control gate cannot be used by more 
than one process class at a time. A 
C-process should use SGS primarily as 
a means of simulating the occurrence 
of some system event. 

6.5 Deadlock Detection 

All deadlock avoidance techniques 
depend either on predicting the order 
in which data will be accessed, or on 
bounding the domain of access to a 
point where redundant access control 
is practical. In an event-driven en¬ 
vironment, it is never possible to 
predict the order in which events 
will occur, nor is it always possible 
to place limits on the scope of data 
access. Consequently, R-process 
deadlocks are certain to occur in 
some EPSILON systems, and have a fair 
probability of occurrence in many 
systems. 

If a group of C-processes become in¬ 
volved in a deadlock, those processes 
cease to advance but other processes 
in the system are unaffected. Howev¬ 
er, if a group of R-processes become 
deadlocked, and if the number of CPU 
in the system is less than the number 
of deadlocked processes, all pro¬ 
cesses of dispatching priority lower 
than the highest priority process 
involved in the deadlock (in partic¬ 
ular, all C-processes) will also 
cease to advance. Dispatching will 
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not assign a CPU to those processes 
because the deadlocked processes re¬ 
main in running condition. 

EPSILON systems therefore include a 
mechanism for detecting R-process 
deadlocks. The mechanism, which is 
integrated with R-process dispatch¬ 
ing, works in conjunction with the 
promotion mechanism used to clear an 
R-process through a closed access 
control gate [Section 5.10]. 

o The closure of a sequence of 
gates by a process can be repres¬ 
ented as a graph of directed line 
segments, where the end points of 
each segment correspond to gates 
closed in sequence, and the di¬ 
rection of each segment indi¬ 
cates the order of succession. 
It is known that if a directed 
graph of this kind is drawn for a 
group of processes, then the ex¬ 
istence of a circuit in the graph 
is equivalent to the existence of 
a deadlock among the processes. 
Hence, the essential form of a 
deadlock of two or more processes 
is that each process tries to 
close the same set of gates, 
equal in number to the number of 
processes, and each gate is first 
closed by a different process. 

o To visualize events that might 
cause a deadlock, suppose there 
are processes PI,P2,...,Pn, num¬ 
bered in order from low to high 
dispatching priority, and n 
gates, numbered so that 


PI 

will 

close 

Gl,G2, . . 

. , Gn 

P2 

will 

close 

G2,G3, . . 

. , Gl 

P3 

will 

close 

G3,G4, . . 

. ,G2 

Pn 

will 

close 

Gn > Gl > .. 

. , Gn 


PI is initiated first and closes 
Gl. Before it can close G2, P2 
is initated and closes it; before 
P2 can close G3, P3 is intiated 


and closes it; before P3 can 
close G4, P4 is initiated and 
closes it; this sequence contin¬ 
ues until eventually Pn is initi¬ 
ated and closes Gn. 

Since Pn is the highest priority 
process, it continues to advance 
until it attempts to close Gl. 
At that point Pn is suspended, 
process PI is promoted in priori¬ 
ty above it, and if not already 
running will be assigned a CPU 
and start running in place of Pn. 
PI then causes promotion of P2, 
which causes promotion of P3, 
which causes promotion of P4, 
until eventually Pn is promoted 
and starts running again. Pn was 
suspended trying to close Gl, so 
it immediately tries again to 
close that gate; Pn is suspended 
as a result of that effort and PI 
promoted a second time. PI then 
causes promotion of P2, which 
causes promotion of P3, until 
eventually Pn is promoted and 
starts running again. This cycle 
of promotion continues indefi¬ 
nitely, as all processes are sus¬ 
pended trying to close a gate 
already closed. 

o The occurrence of indefinite 
promotion, as in the example, 
characterizes all R-process 
deadlocks, so it provides the 
means by which they can be de¬ 
tected. A system parameter, 
called the promotion limit, is 
defined at system initializa¬ 
tion. If an R-process is pro¬ 
moted beyond this limit, it is 
considered to be party to a dead- 
1 ock. 

The promotion limit specifies the 
number of times a process can be pro¬ 
moted trying to close any one gate 
before a deadlock is presumed to be 
established. If there are N R-pro¬ 
cess sources in a system with M CPU, 
then from the R-process dispatching 
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rules [Section 4.6], at most NM pro¬ 
cesses can be involved in a deadlock. 
The number NM+1, called the nominal 
limit, is therefore an upper bound to 
the number of promotions which can 
actually occur before the onset of a 
deadlock. For any given system, it 
may be possible to determine a small¬ 
er upper bound, so the promotion lim¬ 
it may be set at any value. If no 
alternative is specified, the system 
will assume the promotion limit to be 
equal to the nominal limit. 

When a process is promoted beyond the 
promotion limit, action is initiated 
to try to recover from the deadlock, 
if possible. 

o Bit 1 of field PFLG in the PIC of 
the process is set to 1, and an 
access exception is raised. The 
exception occurs as soon as the 
process starts running, so the 
pending close is not executed. 

o Bit 1 is turned off whenever a 
process opens a gate. Hence, if 
the exception module is able suc¬ 
cessfully to back out of a gate, 
some other process in the dead¬ 
locked group wi11 be able to 
close it. If a deadlock still 
persists, some process will 
again exceed the promotion limit 
and be given an opportunity to 
open a gate. If all processes 
which exceed the limit can open a 
gate, the deadlock will be broken 
with full recovery. 

o If a process exceeds the promo¬ 
tion limit with bit 1 on it is 
terminated. So, if any of the 
deadlocked processes have no ex¬ 
ception module defined, or the 
exception module does not open a 
gate, the gates owned by that 
process will be opended by termi¬ 
nation service [Section 6.61. In 
that case, the deadlock will be 
broken, but the data protected by 
the gates is likely to have been 


damaged beyond recovery. 

If processes can avoid making irre¬ 
versible changes in data before clos¬ 
ing all access gates required, then 
recovery from a deadlock is always 
possible. If irreversible changes 
cannot be avoided, the effect of the 
loss of data integrity sustained in a 
deadlock can only be determined in 
the context of each application or 
set of applications. 

6.6 Termination 

A request for termination of an 
R-process is triggered by either an 
EXIT or TERM instruction, both of 
which behave externally the same as 
when executed within a C-process 
[Section 5.12]. The internal micro¬ 
code which carries out actual de¬ 
letion of the process does not have 
the same behavior, as its activity 
cannot be inserted into a computation 
cycle. 

o A termination request sets bit 3 

of field PFLG of the PIC to 1. 
When this bit is on, dispatching 
will not assign a CPU to the pro¬ 
cess if it has been suspended, 
but will substitute termination 
service in its place. 

o If the termination request is 

triggered when the process is 
promoted, bit 3 is set and an 
OPEN is executed referencing the 
gate last closed by the process. 
If termination service becomes 
active with the process again 
promoted, an OPEN is executed re¬ 
ferring to the gate which caused 
promotion. In either case, the 
OPEN will cause the process to be 
reduced to its normal dispatch¬ 
ing priority and suspended. 

o Eventually termination service 

will become active for the pro¬ 
cess at its normal dispatching 
priority. If the process has no 


Chapter 6 


79 


R-Processes 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


I/O requests outstanding at that 
time, and if it is not holding 
any access control gates, all 
spaces in private custody of the 
process are deleted, the linkage 
control stack is depleted, the 
state vector is deleted from 
M-storage, and the process dis¬ 
appears from the system. 

o If it is holding one or more 
gates, or has I/O requests yet to 
be completed, the state vector 
remains in ^-storage, but the 
process is removed from the ac¬ 
tive list for its source. Each 
time after that a CLOSE is exe¬ 
cuted referencing a gate which 
belongs to the process, an OPEN 
will be inserted in front of it. 
Each time an I/O request is com¬ 
pleted, the request space is de¬ 
leted if returned to the process 
[Section 7.81. Eventually all 
gates belonging to the process 
will be opened and all I/O re¬ 
quests completed; the state vec¬ 
tor will then be deleted from 


M-storage. 

Once an R-process is removed from the 
active list of its source, it does 
not count to delay a pending condi¬ 
tion for the source from becoming ef¬ 
fect i ve. 

6.7 Exception Handling 

The treatment of R-process excep¬ 
tions with codes 1 through 9 is es¬ 
sentially the same as that for 
C-processes [Sections 5.13, 5.143. 
However, the exception module must be 
an M-space, and as an R-process can¬ 
not execute the DXM instruction, the 
module must be specified with the 
process model. 

Decimal and floating-point instruc¬ 
tions cannot be executed within 
R-processes, so exception codes 10 
through 15 cannot occur. Consequent¬ 
ly, as SXM is not a modal instruc¬ 
tion, the low-order six bits of the 
exception mask are available for use 
by software. 


6.8 instruction Descriptions 


STORE SOURCE LIST 


SSL R1,D2CX2,B2) <RX> 

Source identifiers are stored in successive half-words starting at the 
second operand location, up to the number of half-words specified by the value 
contained in arithmetic register Rl. Subsequently the content of the register 
is replaced by the difference between its original value and the number of 
sources on the system. 

Identifiers are stored in order of decreasing dispatching priority, 
starting with the source of highest priority. If storing an identifier would 
require exceeding the space boundary, the instruction is terminated at that 
point with condition code 3, and without decrementing register Rl. If the in¬ 
struction is completed, the condition code is set according to the value of 
arithmetic regi ster Rl. 
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Process Class: C,R 

Condition Code : 

0 Difference is zero 

1 Difference is negative 

2 Difference is positive 

3 Insufficient space allowed 

Exceptions 1 None 


CONNECT R-PROCESS MODEL 


CRPM R1,D2(B2) <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is suppressed with a 
data exception if arithmetic register R1 does not contain the identifier of a 
process source. The instruction is terminated with condition code 1 if field 
RMMOD of the RMDB located by the second operand does not contain either a null 
pointer or a pointer to a module M-space for which field RMLOC designates a 
valid instruction location within the space, or if field RMXMD does not con¬ 
tain either a null pointer or a pointer to a module M-space. 

If a valid source identifier is contained in Rl, and if there is no pro¬ 
cess model connected to the source, the instruction is terminated with condi¬ 
tion code 1 if the first four bytes of field RMCTX do not contain a null 
pointer or a pointer to an ordinary M-space in private or family custody of 
the defining process. If the instruction is not terminated, an attempt is 
made to obtain M-storage for RMDB data. The instruction is terminated with 
condition code 3 if storage is not available. If storage is available, the 
RMDB information is stored into it and the instruction completion sequence is 
entered. 

If a process modal is already connected to the source, it is tested for 
deletion status. Deletion is allowed if the model is in custody of the family 
of the process within which the instruction is being executed, or if the model 
is in public custody. If deletion is not allowed the instruction is termi¬ 
nated with condition code 2. If delation is allowed, and if bit 6 of field 
RMFLG of the proposed new RMDB is 1, the process model data is disconnected 
from the source, the entry context space is deleted if bound to the model, and 
the instruction is completed with condition code zero. 

If bit 6 of field RMFLG is zero, the RMDB data for the existing model is 
replaced by the new RMDB data, and the instruction completion sequence is en¬ 
tered. Prior to replacement, the proposed entry context space is compared to 
the entry context space of the existing model. If the spaces are not the same, 
and if the space of the existing model is bound to its custody, that space is 
deleted from the system. 

The instruction completion sequence tests bit 3 of field RMFLG to deter¬ 
mine the custody of any non-null entry context space. If the bit is zero, the 
space is bound to the custody of the process model; if the bit is 1, the custo¬ 
dy of the space is not altered. The instruction is then completed with condi- 
tion code zero. 

If the process model is deleted or replaced, any active members of its 
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process model family continue to exist until their termination is specifically 
requested. 

Process Class: R 

Condition Code: 

0 Model connected or deleted 

1 Invalid RMDB format 

2 Delation not allowed 

3 Storage not available 

Exceptions ; 

Specification 
Data 


CONNECT R-PROCESS MODEL INDIRECT 


CRPMI R1,R2 <RR> 

The instruction is terminated with condition code 3 if either arithmetic 
register R1 or arithmetic register R2 do not contain process source identifi¬ 
ers. 

If both registers contain valid identifiers, the instruction is termi¬ 
nated with condition code 1 if a process model is not connected to the source 
identified by register R2. If a model is connected with an entry context 
space which is not bound to it, the instruction is terminated with condition 
code 1 if the space is not in custody of the process within which the instruc¬ 
tion is being executed. If the instruction is not terminated, it is then pro¬ 
cessed as if it were a CRPM referring to the source identified by the contents 
of arithmetic register Rl, with an RMDB identical to that of the other source. 

If the instruction is completed with condition code zero, a reference is 
generated specifying that the RMDB data of the source identified by register 
Rl resides with the source identified by register R2. The reference is pre¬ 
served until execution of another instruction which connects a process model 
to the source identified by register Rl. 

Process Class 1 R 

Condition Code 1 

0 Model connected or deleted 

1 Invalid RMDB format 

2 Deletion not all owed 

3 Source not present 

Exceptions-' None 
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STORE SOURCE STATUS 


SRCE R1,D2CB2) <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is terminated with 
condition code 2 if arithmetic register R1 does not contain the identifier of 
a process source, and with condition code 1 if there is no process model con¬ 
nected to the source. 

If the source has a process model connected, the RMDB data for the model 
is stored into successive words starting at the second operand location. The 
instruction is then completed with condition code zero. 

Process Class: c,R 

Condition Code : 

0 RMDB stored 

1 Process model not connected 

2 Source not present 

3 

Except? ons = 

Specification 


SIGNAL SOURCE 


SGS R1,R2 <RR> 

The instruction is terminated with condition code 3 if arithmetic register 
R1 does not contain the identifier of a process source, and with condition 
code 2 if there is no process model connected to the source. 

If a process model is connected, and if pointer register R2 contains a 
null pointer, the conditions are raised which signal the event associated with 
the process source. The contents of arithmetic register R2 are retained as 
communication data to be passed to any process initiated as a result of the 
signal. The instruction is then completed with condition coda zero. 

If pointer register R2 identifies a non-null space, the instruction is 
suppressed with an access exception if the space is not in private or family 
custody of the process within which the instruction is being executed. If the 
instruction is not suppressed, a null pointer is loaded into pointer register 
R2 and into any other pointer register of the process which contains a pointer 
to the space; the reference count of the space is decremented by 1 for each 
pointer loaded. The custody flag is turned off, the space is assigned to the 
source, and the contents of arithmetic register R2 are retained as communi¬ 
cation data to be given to the process initiated as a result of the SGS signal. 

If the reference count becomes zero, the SGS signal is transmitted to the 
source and the instruction is completed with condition code zero. If the ref¬ 
erence count is not zero, the SGS signal is held in abeyance and the instruc¬ 
tion is completed with condition code 1. The SGS signal will be transmitted 
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whenever the reference count subsequently becomes zero. 

Process Class : C,R,D 

Condition Code: 

0 Signal accepted 

1 Signal delayed 

2 Process model not connected 

3 Source not present 

Exceptions : 

Access 
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7.0 D-PRCCESSES: INPUT/OUTPUT 

This chapter describes I/O opei— 
ations as they appear to processes, 
I/O instructions, device control, 
and D-process functions. The general 
appearance of the attachment intei— 
faces to I/O devices is discussed, 
but the publications dedicated to the 
interfaces should be consulted for a 
detailed description of interface 
logical and electrical charactei— 
istics. 

7.1 I/O Devices 

A device is an I/O device of an 
EPSILON system if it is connected to 
the system through an I/O attachment 
interface and conforms to the signal¬ 
ling protocol of that interface. 
When an I/O device is installed on a 
system, either at the factory or in 
the field, it is assigned a unique 
16-bit identifier by which it is des¬ 
ignated whenever a specific refei— 
ence to the device is required. A 
device identifier may have any value 
except zero, which is reserved as a 
null device designation. An EPSILON 
system therefore admits a maximum of 
65,535 I/O devices, but some models 
may restrict configurations to a 
total substantially less than this. 

The actual number and specific iden¬ 
tifiers of the I/O devices on a given 
system can be obtained by execution 
of a STORE DEVICE LIST instruction 
(STDL), which stores device identi- 
fiers in successive half-word loca¬ 
tions. The number of half-words to 
be stored is specified in the STDL 
instruction, and a count of the num¬ 
ber of identifiers not stored is re¬ 
turned at instruction completion. 
The identifiers are stored in order 
of increasing numerical value, 
starting with the identifier of low¬ 
est value. 

An I/O device is always a D-process 


source. It may also be an R-process 
source if so designed and attached. 
The conditions under which an I/O de¬ 
vice can become an R-process source, 
and the events it can represent as 
such a source, are peculiar to the 
device, and are specified in the in¬ 
dividual publications for the de¬ 
vice. If an I/O device is both an 
R-process and D-process source, each 
source acts independently of the oth¬ 
er. The dispatching priority as¬ 
signed to the device as an R-process 
source does not affect dispatching of 
its D-procesaes, nor is there any 
special relationship between the 
processes initiated from the two 
sources. However, as the I/O device 
identifier is required to serve for 
identification of both sources, the 
sources do have a built-in 
realtionship which can assist their 
processes to co-operate. 

Any process can obtain information 
about a device by executing a STORE 
DEVICE DESCRIPTION instruction 
(STDDW), which supplies the Device 
Description Word CDDW) of a specified 
device. A DDW is a double-word with 
the format described in figure 7.1. A 
DDW is generated for each device when 
it is installed. The device classi¬ 
fication combination (CLASS and 
TYPE) defines the device well enough 
to distinguish it from all other de¬ 
vices with similar characteristics 
(e.g. 3330 vs 2314 disc). The DDEP 
field information is supplied by the 
device designer to supplement this 
information; it usually describes 
specific features peculiar to the de¬ 
vice. The format of the DDEP field 
is therefore dependent on the device 
classification, and is described in 
the individual device publications. 

Figure 7.2 is a list of the classi¬ 
fication combinations so far speci¬ 
fied. The list is strictly for 
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CLASS 

TYPE 

CHAR 

STAT 

DQEP 



Figure 7.1 

Device Description Word 


Field 

Offset 

Bvtes 

Description and Use 


CLASS 

0 

1 

A code specifying the general class of the device. 


TYPE 

1 

1 

A code specifying the type of device within 
class. 

the 

CHAR 

2 

1 

Bits describing characteristics of the device. 



Bit 

Value 

Siqnificance 



1 

0 

This I/O device is not an R-process source 




1 

This device is an R-process source 



2 

0 

There is a single I/O path to the device 




1 

The device is connected to more than one I/O attach- 




ment interface 



3-6 

- 

Reserved 



7 

0 

Normal 




1 

Additional device characteristi cs data available 


Field 

Offset 

Bvtes 

Description and Use 


STAT 

3 

1 

Bits describing the operational status current 
the devi ce. 

for 


Bit 

Value 

Siqnificance 



0 

0 

Normal 




1 

The device is inaccessible because all paths to 
are inoperative 

it 


1 

0 

Normal 




1 

The device has been suspended pending repair of 

dam- 




age 



2 

0 

Normal 



Intervention required to clear a condition blocking 
correct device operation 
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3 


0 

1 


Normal 

I/O operations being held pending a signal from the 
device 


4-5 


Reserved 


6 


0 

1 


Normal 

I/O request pending 


7 


0 

1 


Device not busy 
Device busy 


Fi eld Offset Bvtes 


Description and Use 


DDEP 4 4 


Defines specific characteristics within the device 
class and type. 


classification, and does not corre¬ 
spond to attachment capability. 
Devices which appear in the list need 
not be attachable to any EPSILON sys¬ 
tem. Devices which can be attached 
may not appear in the list because 
classification numbers have not yet 
been selected. 

Bit 7 of field CHAR is turned on to 
indicate that the device can supply 
more device dependent descriptive 
data than will fit into field DDEP. 
In that case, the device will respond 
to some SENSE instruction with the 
additional information. However, as 
a SENSE instruction for a device can 
only be executed within a D-process 
of the family associated with the de¬ 
vice, device designers should pro¬ 
vide the most widely sought 
information in the DDEP field of the 
DDW. 

7.2 Process Modal connection 

Transmission of data between an 
EPSILON sytstem and an attached I/O 
device is always controlled by the 
activity of a D-process associated 
with the device. In order for such a 
D-process to be initiated, a D-pro¬ 
cess model must be connected to the 
device by means of the CONNECT D-PRO¬ 


CESS MODEL instruction (CDPM), or the 
CONNECT D-PROCESS MODEL INDIRECT in¬ 
struction (CDPMI). If a model is not 
connected, I/O requests from pro¬ 
cesses will be rejected, and requests 
for attention from the device will be 
ignored. 

The connection data for these in¬ 
structions is supplied by a D-Process 
Model Definition Block CDMDB). A 
DMDB must begin on a word boundary 
and have the format described in fig¬ 
ure 7.3. The CDPM and CDPMI instruc¬ 
tions, which can be executed within 
any C-process or R-process, wi11 con¬ 
nect a new process model, replace an 
existing one, or delete a model en¬ 
tirely, depending on the content of 
the DMDB. For CDPMI the DMDB data is 
obtained from a model already con¬ 
nected to some device, while for CDPM 
it is obtained from a location in 
some M-space. 

o A new model is connected if there 
is not already one connected to 
the device. If a model is con¬ 
nected and if deletion is al¬ 
lowed, it will be replaced or 
deleted; if deletion is not al¬ 
lowed, the connection attempt 
will be rejected. Replacement 
occurs if bit 6 of field DMFLG is 
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Device 


Unspecified 

Unit record 
2540 card reader 

2540 card punch 
1442/2596 read punch 
1403/1404 printer 
2671 paper tape reader 
1419 mag char reader 
1275 optical reader 

System console 

3210 console keyboard 
3215 console keyboard 

Magnetic tape 

2400 series tape 
3400 series tape 

DASD 

2311 disc storage drive 
2301 parallel drum 
2321 data cell drive 
2314 disc storage 
3330 disc storage 

Communications controller 
2701 parallel adapter 

3704 controller 

3705 controller 
3790 subsystem 

Communications terminal 
1050 

2740 

2741 

Character display 

2260 display station 
3270 display system 


Graphic interactive 
2250 display unit 
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Figure 7.3 

D-Process Model Definition Block 


Field Offset Bytes 

DMMOD 0 4 

DMFLG 4 1 

Bit Value 
0 0 

1 

1 0 

1 

2 0 

1 

3 0 
1 

4 0 
1 

5 0 
1 


Description and Use 


A pointer to the module M-space containing the ini¬ 
tial instruction sequence to be executed by every 
process of the process family. 

Bits defining conditions of usage for the process 
model and members of the family. 

Significance 

Collect process statistics under control of statis¬ 
tical collection instructions 
Do not collect process statistics 

The initial value of the domain identifier for pro¬ 
cesses of the family is to be the identifier of the 
entry context space 

The initial value of the domain identifier is to be 
that of the domain for which the device is reserved, 
or that of the common domain if the device is not re¬ 
served 

The domain identifier may vary during execution 
The domain identifier is fixed during execution 

The entry context space identified by field DMCTX is 
to be bound to custody of the process model 
Do not change custody of the entry context space 

I/O requests are to be accepted from any process 
I/O requests are to be accepted only from processes 
whose domain identifier matches that of the domain 
for which the device is reserved 

This device can be reserved for a specified domain 
This device cannot be reserved 
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6 


0 

1 


Normal 

This process model is to be deleted (is indirectly 
connected) 


7 


0 Place this process model in system custody if custody 

is transferred 

1 Place in public custody on a transfer of custody. 


Field Offset Bvtes 


Description and Use 


DMLOC 5 3 Base address within the module space identified by 

field DMMOD of the initial instruction sequence to be 
executed by members of the process model family. 


DMXMD 8 4 


A pointer to the module space containing the initial 
instruction sequence for handling process exceptions. 


DMCTX 12 4 


A pointer to an ordinary M-space which becomes the 
entry context space for processes of the family. 


zero, deletion if the bit is 1. 
Replacement consists of deleting 
the existing model together with 
any I/O requests pending on the 
device, followed by connection 
of the new model. Deletion will 
not occur if the connection at¬ 
tempt is rejected for any reason. 

o The connection attempt will be 
rejected if any of the fields 
DMMOD, DMLOC, DMXMD, or DMCTX are 
invalid. Field DMMOD must con¬ 
tain either a null pointer or a 
pointer to a module M-space for 
which field DMLOC designates an 
instruction location which lies 
within the space. Field DMXMD 
must identify either the null 
space or a module space. Field 
DMCTX must contain either a null 
pointer, or a pointer to an ordi¬ 
nary M-space in private or family 
custody of the defining process. 

o When connection is complete the 
DMD8 area supplied for a CDPM in¬ 
struction is immediately avail¬ 
able for new use, as the process 
modal control information is re¬ 
tained by the system in an area 


withdrawn from the M-storage 
pool at system initialization. 

o If CDPMI is used and connection 
or deletion is successful, only 
the fact of indirect connection 
is maintained; the DMDB resides 
with the referenced device, or 
with the device directly con¬ 
nected if there is an indirect 
connection chain. Any indirect 
connection reference is retained 
until a direct connection is 
made, irrespective of the con¬ 
nection state of the referenced 
device. 

The STORE DEVICE STATUS instruction 
(STDS) can be executed within any 
process to determine if a process 
model is connected to a device. The 
instruction will supply the DMDB of 
the connected model, or an indication 
that no model is connected. If a 
DMDB is stored, indirect connection 
is indicated by turning on the de¬ 
letion bit of field DMFLG. A con¬ 
nected D-process model is assigned to 
the custody of the family of the de¬ 
fining process, and can be replaced 
or deleted only by a custodian pro- 
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cess. If the custodian family is 
deleted, the D-process model is 
transferred to the alternative cus¬ 
tody indicated by bit 7 of field 
DMFLG of its DMDB. 

When a D-process model is deleted, 
spaces held in family custody are de¬ 
leted with it, as is the entry con¬ 
text space if bound to the model. 
I/O requests pending on the device 
are then deleted, followed by de¬ 
letion of the model. However, if 
deletion is an intermediate step in 
replacement of the model, and if the 
entry context space for the new model 
is the same as that of the old, the 
space remains in existence. Its cus¬ 
tody is then determined by the value 
of bit 3 of field DMFLG of the new 
DMDB. 

7.3 I/O Requests 

Every I/O device installed on an 
EPSILON system has a queue associated 
with it, called the request queue for 
the device. A request queue is con¬ 
sidered to be part of the device; it 
is not distinguished by a separate 
name or queue index, but is refei— 
enced using the device identifier. 
However, when a D-process model is 
connected to a device, the request 
queue becomes associated with the 
model, and provides the basic func¬ 
tions of an input queue. In partic¬ 
ular, an item entered into the queue 
when the queue is empty automatically 
triggers a request for initiation of 
a process of the associated family. 


other attention message still resi¬ 
dent in the queue. Attention signals 
therefore take precedence over I/O 
requests by processes. 

RIO is a modal instruction which can 
be executed within any process. The 
request will be rejected if the de¬ 
vice does not exist or has been sus¬ 
pended for any reason, if there is no 
D-process model connected to the de¬ 
vice, or if the request space is not 
an ordinary M-space in custody of the 
requesting process or process fami¬ 
ly. If RIO is executed within a 
D-process, the request will also be 
rejected if the device is the one 
associated with the process. In ad¬ 
dition, domain identification can be 
used to restrict the set of processes 
that can make valid requests of a 
given device [Section 7.91. 

If the request is accepted, the 
M-space specified in the instruction 
becomes the new bottom item of the 
queue. As in the case of an ENQ in¬ 
struction, the new item loses 
addressability as a space, passing 
out of the custody of the enqueuing 
process or process family into the 
custody of the system. Similarly, 
the reference count is decremented by 
substitution of null pointers into 
pointer registers referencing the 
space, and entry into the queue is 
delayed until the count becomes zero. 
However, in contrast to an input 
queue, a process can retain a con¬ 
nection to an item in a request 
queue. 


Items are entered into a request 
queue either by action of the associ¬ 
ated device, or by means of the RE¬ 
QUEST INPUT/OUTPUT instruction 
(RIO). An item is entered for the 
device when it raises an attention 
signal through an I/O attachment 
interface. System microcode re¬ 
sponds to the signal by placing a 
special message in the queue ahead of 
all ordinary items, but behind any 


o A space entered into a request 
queue is placed into a special 
state, called request state, 
unless the 'no request state' 
option of the RIO instruction is 
selected. Request state is as¬ 
sumed to indicate that the activ¬ 
ity of the requesting process is 
i n some way dependent on the I/O 
operation, and that the process 
intends to remain in existence 
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until there is some disposition 
of the request. 

o A space placed into request state 
therefore causes the I/O request 
count of the process executing 
the RIO to be incremented. The 
process is also allowed to refei— 
ence the space in order to test 
progress of the request. For 
that purpose, instead of loading 
a null pointer into the pointer 
register actually used to refei— 
ence the space in the RIO 
instruction, the retained status 
of the register is simply changed 
to indicate that the space is 
temporarily unavailable. As 
long as the space remains in 
request state, the requesting 
process will receive the 'tempo¬ 
rarily unavailable' condition 
coda return from an LP or LPR in¬ 
struction [Section 3.3]. 

o A space remains in request state 
when a D-process serving the re¬ 
quest queue acquires custody of 
it; it is taken out of request 
state when that process disposes 
of it with an END I/O REQUEST in¬ 
struction. Disposition of the 
request causes the I/O request 
count of the original requesting 
process to be decremented, and 
usually returns the space to cus¬ 
tody of that process [Section 
7.8] . 

o Suppression of request state is 
assumed to indicate that the re¬ 
questing process is not depen¬ 
dent on the I/O operation, or 
that communication with the 
D-process serves some purpose 
other than I/O. Consequently, 
the action of the RIO instruction 
in that case is the same as the 
action of an ENQ instruction: the 
I/O request count of the process 
is not incremented, and all regi¬ 
sters referencing the space, 
including the register desig¬ 


nated in the instruction, are 
loaded with null pointers. 

The RIO instruction is synchronous to 
all processes within which it is exe¬ 
cuted, but if request state is not 
suppressed the normal mode is to 
place C-processes and D-processes 
into I/O wait state until the request 
is completed. Processes can always 
avoid the wait by exercising the 'do 
not wait' option of the instruction. 

A process which is not in I/O wait 
state can follow the progress of a 
request by continuing to load the re¬ 
tained pointer to the request space 
until the condition code indicates 
the disposition of the space. Howev¬ 
er, a positive test is provided by 
the TEST INPUT/OUTPUT instruction 
(TIO). TIO is a modal instruction 
which can be executed within any pro¬ 
cess. When executed within an R-pro- 
cess, 

o if the specified space is not in 
request state, condition code 
zero indicates that the space has 
been returned to the custody of 
the requesting process. Condi¬ 
tion code 3 indicates that the 
space is not in process or family 
custody; its actual availability 
can then be tested by an LP or 
LPR instruction. 

o If the space is in request state, 
the process within which the TIO 
is being executed must be the re¬ 
questing process or an access ex¬ 
ception will result. If it is 
the requesting process, condi¬ 
tion code 2 is returned if the 
space is resident in a request 
queue, and condition code 1 if it 
is not, indicating the request 
has been received by some D-pro- 
cess. 

When TIO is executed within a 
C-process or D-process, the pro¬ 
cess is placed into I/O wait dis- 




Chapter 7 


92 


D-Processes 



Principles of Operation 
The EPSILON System 


patching condition if the 
request is not complete. The 
process is removed from I/O wait 
when the referenced space is dis¬ 
posed of by the D-process servic¬ 
ing the request, at which time 
the TIO will be retried. Conse¬ 
quently, only condition codes 
zero or 3 can be returned to a 
C-process or D-process. 

7.4 D-process Environment 

There are no requirements placed 
on the contents of an M-space en¬ 
tered into a request queue, and 
no restrictions on the use of the 
space by the D-process family 
serving the queue. The 
presumption is that the space 
will contain a sat of instruc¬ 
tions for what is to be done on 
the device. These instructions 
are not defined by the architec¬ 
ture, but are arbitrary codes, 
perhaps privately agreed between 
the requesting process and the 
D-process family, perhaps stand¬ 
ard to some programming system. 
A requesting process may also 
provide data to be used in con¬ 
nection with the request itself; 
for example, it could include a 
code indicating how the D-pro¬ 
cess is to dispose of the request 
space. 

Although this presumptive use of 
the request space is not neces¬ 
sarily the actual use in any pai— 
ticular case, it does depict the 
kind of activity a D-process may 
need to undertake. The activity 
can extend far beyond simple de¬ 
vice control, as the interpreta¬ 
tion of an I/O request can 
include complex data conversion 
and computation. Consequently, 
D-processes are provided with a 
substantial amount of computa¬ 
tional capability, though less 
than that of C-processes or 
R-processes, and are allowed the 
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ALLOC, FREE, LP, SP, LPIC, CALL, 
RETURN, ENQ, SGS, RIO, TIO, and 
breakpoint instructions. Howev¬ 
er, restrictions are imposed on 
the D-process environment which 
limit the scope of activity of 
any D-process, and constrain the 
relation between a D-process and 
a requesting process. 

o The state vector of a D-process 
consists of the 16 general regi¬ 
sters, a PIC, and internal con¬ 
trol data. The general registers 
have the same appearance as the 
general registers of C-processes 
and R-processes. Register ref¬ 
erences, register usage, and 
storage address generation con¬ 
form to the standard rules 
[Section 2.8]. However all ref¬ 
erences to pointer registers 2 
through 15 are interpreted as 
references to pointer register 
1. In effect, D-processes have 
only two independent pointer 
registers. 

o A D-process manages I/O requests 
specifically for the device with 
which it is associated, and no 
other. It is prevented from even 
trying to manage another device, 
as the system supplies the device 
identifier when an identifier is 
required as an operand of an in¬ 
struction executable only within 
D-processes. This method of en¬ 
forced association also assures 
that a process modal applicable 
to one device of a class is auto¬ 
matically applicable to all de¬ 
vices of the class. 

o Because a D-process and the de¬ 
vice with which it is associated 
are so closely related, D-pro- 
cess models are always 
single-instance. Any member of 
the family is expected to dispose 
of all requests which are in the 
request queue at the time of ini¬ 
tiation, or which are put into 
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the queue prior to its termi¬ 
nation. To reinforce this expec¬ 
tation, all items remaining in 
the request queue when process 
termination is triggered are de¬ 
leted during the termination 
procedure [Section 7.1QJ. 

o In order to allow CPU and PPU to 
operate independently of one an¬ 
other, transmission of data 
between an M-space and an I/O de¬ 
vice is not subject to access 
control gate protection, nor is a 
D-process allowed to execute 
CLOSE or OPEN instructions. A 
D-process i s expected to be able 
to carry out its activity without 
having to share data with other 
processes, or to take special 
action to assure the integrity of 
data in a space not in its pri¬ 
vate custody. Therefore, if a 
pointer is stored in a request 
space for use in data reference 
by a D-process, or to define a 
space for data transmission, the 
requesting process must first 
obtain the correct access condi¬ 
tion for the’space. 

The D-process family associated with 
a device represents the device to all 
other processes. For all practical 
purposes, processes of the family are 
the device, as their interpretation 
of I/O requests determines the ap¬ 
pearance and capability the device 
presents to requesting processes. 
The restrictions on the D-process en¬ 
vironment, and the limitations of the 
peripheral instruction set, are in¬ 
tended to discourage D-processes 
from being diverted arbitrarily to 
general computation or event re¬ 
sponse . 

7.5 Dispatching 

D-process dispatching is a fixed 
function of the system in the sense 
that neither selection routines nor 
device priorities can be used to vary 


the selection algorithm. The algo¬ 
rithm itself is elementary, with pri¬ 
mary selection based on attachment of 
the associated device. 

o Every PPU in the system has an 
internal queue associated with 
it, called its dispatching 
qusua , consisting of D-processes 
ready to be dispatched, or wait¬ 
ing for a device to complete some 
operation [Section 7.7], A PPU 
will be assigned only to D-pro¬ 
cesses in its dispatching queue. 

o A process will always be placed 
in the dispatching queue of a PPU 
whose attachment interface is 
connected to the device with 
which the process is associated. 
If the device is connected to 
more than one attachment intei— 
face, one of the PPU will be se¬ 
lected; the selection is 
arbitrary, except that a PPU will 
not be selected if its attachment 
interface is not operational, or 
if its path to the device is 
blocked for some reason. 

o A process is placed at the tail 
of a dispatching queue, unless 
the entry is in conjunction with 
a wait condition generated by an 
uncompleted I/O operation in¬ 
struction [Section 7.71. In that 
case, the process is placed at 
the head of the queue, or ahead 
of all processes in the queue 
which are not in the same waiting 
condition. 

o When a PPU becomes available, its 
processing mechanism is normally 
assigned to the process at the 
head of the queue. However, if 
the process is in a wait condi¬ 
tion, it will be skipped over and 
the next one in the queue se¬ 
lected. 

Thus, apart from conditions which 
arise because of device delays, pro- 
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cesses are assigned a PPU in FIFO oi— 
der as they become ready. As I/O 
requests are almost all generated by 
C~processe5 and R-processes, this 
algorithm is the simplest one which 
will meet physical constraints and 
preserve the priorities generated by 
process source and computation cycle 
activity. 

7.6 I/O Rgqusst Processing 

A request for initiation of a D-pro- 
cess is triggered whenever an item is 
entered into a request queue which 
was previously empty. If a process 
of the family associated with the 
device already exists* the request is 
considered to be satisfied and no 
further action will be taken. If a 
process does not exist, an initial 
state vector is generated and the new 
process is entered into the dispatch¬ 
ing queue of the appropriate PPU. 

When the process is dispatched for 
the first time, its state vector is 
set with the following initial data. 

o The PIC contains the location of 
the first instruction to be exe¬ 
cuted. Field LCUR contains the 
value of field DMLOC of the DMDB, 
and field PCUR contains a pointer 
to the space identified by field 
DMMOD. 

o Pointer register zero contains a 
pointer to the entry context 
space; the register is set up as 
if it had been loaded with an LP 
instruction. Arithmetic regi¬ 
ster zero contains zero. 

o Arithmetic register 1 con¬ 
tains the identifier of the de¬ 
vice with which the process is 
associated. Pointer register 1 
contains a null pointer. 

o All other general registers con¬ 
tain zero in the arithmetic regi¬ 
ster field and a null pointer in 


the pointer register field. 

o The domain identifier of the pro¬ 
cess is set to the value speci¬ 
fied by the DMDB. 

If field PCUR of the PIC identifies a 
space to which the process does not 
have read access, the process is tei— 
minated immediately and an invalid 
process model system exception is 
raised. If the space is the null 
space, execution is not started. All 
spaces are removed from the request 
queue; spaces in request request 
state are taken out of that state, 
and spaces not in request state are 
deleted from the system. Termination 
of the process is then requested. If 
the space identified by field PCUR is 
not null, instruction execution be¬ 
gins with the first instruction and 
continues until the process termi¬ 
nates or initiates an I/O operation. 
It is expected that the process will 
obtain an I/O request from the re¬ 
quest queue, interpret the informa¬ 
tion in the request space, initiate 
one or more I/O operations as a 
result of the interpretation, dis¬ 
pose of the request space, obtain 
another I/O request, and continue 
this pattern of activity until the 
request queue is exhausted. 

A D-process is not required to con¬ 
form to this expectation, but as oth¬ 
er processes are usually waiting on 
I/O requests, the D-process is re¬ 
quired to conform to the pattern to 
the extent of providing positive dis¬ 
position of every I/O request. To 
enforce this discipline, a request 
space obtained by a D-process from 
the request queue is assigned as the 
current space of the process; it re¬ 
mains current until it is taken out 
of I/O request state. A process can¬ 
not obtain a new I/O request as long 
as it has a space current. If it at¬ 
tempts to terminate with a space 
still current, that space is returned 
to the requesting process before tet— 
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mination occurs [Section 7.101. 

The NEXT REQUEST instruction (NEXT) 
is executed by a D-process to obtain 
a new I/O request. The instruction 
is terminated with a condition code 
indication if the queue is not empty 
but the process has a request space 
current. If the queue is empty the 
instruction indicates either that 
the process is to be terminated, or 
that the instruction is to return a 
condition code for the empty state. 
If a condition code is generated in¬ 
dicating a new request was not ob¬ 
tained, the PPU assigned to the 
process will be returned to dispatch¬ 
ing for a new assignment. The pro¬ 
cess will be placed at the tail of 
its dispatching queue with state vec¬ 
tor preserved, so the instruction 
will actually be completed when the 
process is next dispatched. 

If the request queue is not empty and 
the process has no current space, the 
i tem at the head of the request queue 
is extracted. If the item was en¬ 
tered by an RIO instruction, a point¬ 
er to the request space is placed 
into the pointer register specified 
by the instruction. The space is as¬ 
signed to the private custody of the 
process, and becomes its current 
space. If the item was entered into 
the request queue because of device 
attention, the space holding the 
attention data is not assigned as the 
current space. A D-process need not, 
therefore, take any overt disposi¬ 
tion action for an I/O request origi¬ 
nated by its own device. 

7.7 Input/Output Operations 

There are three instructions which 
are available to D-processes for the 
control of I/O operations: 

o the START DEVICE instruction 
(SDV) will initiate an operation 
on a device 


o the HALT DEVICE instruction 

(HDV) will stop any operation ac¬ 

tually in progress 

o the WAIT DEVICE instruction 

(WDV) will cause the process to 

wait for completion of a speci¬ 
fied I/O operation. 

The operand of an SDV instruction is 
a communication block called an I/O 
Request Block (IORB), which contains 
the I/O command string which the de¬ 
vice is to execute. A command string 
consists of a device operation, 
called a command, and a set of 
M-space areas to be used for data 
transmission. All of the areas must 
be contained in the same M-space, but 
their relative locations within the 
space are not restricted. Each area 
is defined by a double-word, which 
contains the base address of the area 
in the first word, and the extent of 
the area in a 16-bit field of the 
second word. The first double-word 
of a command string contains the com¬ 
mand, and each double-word of the 
string except the last contains a 1 
in the first bit of the second word. 

In effect, a command string has the 
format of an S/360 COW string with 
data chaining [P0P360 : 105]. The for¬ 
mat is illustrated in figure 7.4, in 
which the ADDR and EXT fields define 
the base address and extent of the 
areas. The command contained in 
field CMND of a command string has 
the structure of a S/360 command 
[POP360:105], but with modifier bits 
(M) and basic code (XX) as described 
in figure 7.5. 

When data is transmitted under con¬ 
trol of a command string, the first 
byte is associated with the base ad¬ 
dress of the first area, and succes¬ 
sive bytes with addresses in 
ascending order. When the first area 
is exhausted, the next byte is asso¬ 
ciated with the base address of the 
second area, and successive bytes 
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Command 

WRITE 

READ 

CONTROL 


CMND 

ADDR1 

1 

////////////// 

EXT 1 

//////// 

ADDR2 

0 

////////////// 

EXT2 



Command String Format 


MMMMMMXX 


Figure 7.5 
Command Codes 


XX Description and Use 

0 Data is to be transmitted from the areas defined by 

the command string to the device. 

1 Data is to be transmitted from the device to the areas 
defined by the command string. 

2 Control information is to be transmitted from the 
areas defined by the command string to the device. 
Control information specifies action not involving 
data transmission. The action may be entirely speci¬ 
fied in the modifier bits, or may require additional 
data. Every device will treat a CONTROL command with 
all modifier bits cero as a null operation; the de¬ 
vice will respond by completing the I/O operation but 
will taka no other action. Apart from the null opei— 
ation, the format of the control information is pe¬ 
culiar to the device, and is described in device 
publications. 
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SENSE 


Sense information is to be transmitted from the de¬ 
vice to the areas defined by the command string. 
Sense information can describe device charactei— 
istics, status, or unusual conditions detected during 
execution of the previous command string. The amount 
of sense information supplied varies with the device, 
as does the format, and details are supplied in de¬ 
vice publications. All devices, however, are re¬ 
quired to supply the following information in the 
first byte of sense data transmitted in response to a 
SENSE command with all modifier bits zero 1 


Bit Value 


Siqnificance 


0 0 
1 


1 0 
1 


2 0 
1 


3 0 

1 


Norma 1 

The previous command was rejected because it could 
not be executed by the device 

Normal 

Intervention is required to clear a condition which 
prevents the device from operating properly (e.g. 
printer out of paper) 

Normal 

The device detected an error in data value during the 
previous operation which it was unable to correct 

Normal 

The device detected an equipment malfunction during 
the previous operation 


4 


0 

1 


Normal 

The device detected an error in data format or re¬ 
cording during the previous operation 


5 


0 

1 


Normal 

A timing error occurred during the previous operation 
which caused incorrect data transmission 


6-7 - Reserved 


with ascending addresses, and the as¬ 
sociation continues from area to area 
until all areas are exhausted. If 
data transmission is terminated 
without an exact match between areas 
and transmitted bytes, the trans¬ 
mission is said to be inexact. Inex¬ 
act transmission occurs if 

o an address is generated which 
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lies outside the M-space; trans¬ 
mission stops with the byte which 
would have been associated with 
the address 

o a device transmits fewer bytes on 
input than the areas can contain, 
or the device wants to transmit 
additional bytes after the areas 
are filied 
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o a device expects more bytes on 
output than are contained in the 
areas. 

Inexact transmission is always noted 
in the information returned at the 
completion of an I/O operation, but 
is not treated as an error. 

Part of the information in an IORB is 
supplied by the process requesting 
the I/O operation, and the remainder 
is supplied by the system at oper¬ 
ation completion. An IORB must begin 
on a word boundary and have the for¬ 
mat described in figure 7.6. 

When an SDV is executed within a 
D-process, the instruction will be 
rejected without attemptimg to 
signal the device if the SPACE field 
of the IORB does not identify an 
M-space, or if the D-process does not 
have the correct I/O access to the 
space. The I/O access of a D-process 
to an M-space is defined to be the 
same as the addressing acces of the 
D-procass to the space, if the pro¬ 
cess has access to it. If the pro¬ 
cess does not have access, but has a 
current request space, than the I/O 
access of the D-process is the same 
as the addressing access to the space 
of the requesting process associated 
with the current space of the D-pro- 
cess. Using these rules, a READ or 
SENSE command will be rejected if the 
process does not have I/O write ac¬ 
cess, and a WRITE or CONTROL command 
will be rejected if it does not have 
I/O read access. 

SDV will also be rejected if the de¬ 
vice status indicates the operation 
cannot proceed. Device status is set 
by execution of a SET DEVICE STATUS 
instruction (SDS) within a D-process 
associated with the device, usually 
when a device error is detected. 
Four separate conditions are recog- 
nized. 

o Inaccessible: the device is in- 
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accessible because all paths to 
the device are inoperative. 

o Suspended: the device has sus¬ 

tained major damage which must be 
repaired before I/O operations 
can be resumed. 

o Intervention Required: operator 

action is required to clear a 
condition which prevents the de¬ 
vice from operating properly. 

o Not Ready: the device cannot exe¬ 
cute I/O operations until some 
unspecified temporary condition 
is cleared. 

The setting of these conditions is 
reflected in the first four bits of 
field STAT of the DDW [Figure 7.13. 
Once set, the conditions can be 
lifted only by execution of another 
SDS by a D-process associated with 
the device. The process usually exe¬ 
cutes the SDS as a result of an at¬ 
tention signal from the device, or at 
completion of a SENSE command which 
indicates a change of status. 

If SDV is accepted, an attempt is 
made to signal the device through the 
I/O interface. If either the inter¬ 
face or the device is busy, the 
D-process is placed into davica wait 
condition, inserted at the head of 
its dispatching queue, and the PPU is 
returned to dispatching. The process 
is removed from device wait when the 
busy condition is cleared, and the 
SDV is retried when the process is 
next dispatched. This procedure will 
be repeated, if necessary, until the 
IORB is accepted by the I/O interface 
mechanism. 

When the IORB is accepted, the pro¬ 
cess is inserted at the tail of its 
dispatching queue, and the PPU is re¬ 
turned to dispatching. The process 
is normally also placed into device 
wait, and so will not be dispatched 
again until the operation is com- 
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Fi eld 
IOST 


Field 

PROCS 

DVID 


IOST 


PROCS 


DVID 


SENSE 


SPACE 


CMSTG 


Figure 7.6 
I/O Request Block 


Offset Bytes Description and Use 

0 1 Cleared to zero by the system at the start of the I/O 

operation. At the end of the operation the system 
turns on the first bit and sets the other bits to de¬ 
scribe the completion status. 


Bit Value 


Significance 


0 


0 

1 


The operation is not yet complete 
The operation has been completed 


1 


0 

1 


The operation was completed without a device or I/O 
interface error 

A device or I/O interface error was detected 


2 


0 

1 


Sense information has been supplied in field SENSE to 
describe the error 

Sense information has not been supplied for the error 


3 


0 

1 


Normal 

Inexact transmission occurred 


4 0 Normal 

1 Inexact transmission was due to addressing exception 

5-7 - Reserved 


Offset Bytes Description and Use 

1 1 Reserved for arbitrary use by the process. The field 

is not examined or altered during the course of the 
I/O operation. 


2 2 The identifier of the device on which the operation 

occurred. The field is supplied by the system after 
operation completion unless the 5DV instruction spec¬ 
ifies otherwise. In that case, the field is avail¬ 
able for use by the process, as it will not be 


l 4 
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examined or altered during the course of the opei— 
ation. 


SENSE 4 


Contains sense information supplied by the system at 
the completion of any operation for which bit 1 of 
field IOST is 1 and bit 2 is zero. The information is 
the same as the first eight bytes of the information 
which is supplied by the device in response to a SENSE 
command with all modifier bits zero. If bit 1 of 
field IOST is zero and bit 3 is 1, the first word of 
the field contains the address generated when trans¬ 
mission was terminated. 


SPACE 12 


A pointer to the M-space in which the areas defined by 
the command string reside. The field is supplied by 
the process. 


CMSTG 16 Var Contains the command string supplied by the process 

to request the I/O operation. 


pleted. However, the process can se¬ 
lect a 'no wait' option with the SDV 
instruciton. In that case, it will 
be dipatched again the next time it 
arrives at the top of its dispatching 
queue, irrespective of the state of 
the I/O operation. A process can se¬ 
lect two other options with SDV. 

o Sense information is normally 

supplied with operation com¬ 
pletion if there is a device ei— 
ror [Figure 7.6], unless the 
information could not be ob¬ 

tained for some reason. If the 
process does not want the stand¬ 
ard sense data automatically 
supplied Cit might preclude get¬ 
ting other sense data), the 'no 
sense data' option can be se- 

1ected. 

o If the process does not require 
the device identifier to be asso¬ 
ciated with an operation, it can 
select the 'no device ID' option. 
Field DVID of the IORB will then 
not be set on operation com¬ 
pletion, and is free for use by 
the process. 


The WDV instruction will cause a 
D-process to wait for completion of 
the I/O operation contained in a 
specified IORB. If bit zero of field 
IOST of the IORB is on, the instruc¬ 
tion will simply be completed as a 
null instruction. If the bit is off, 
the instruction will be rejected if 
the IORB was not the subject of a 
previous SDV which initiated an opei— 
ation not yet complete. If WDV is 
accepted, the process is placed into 
device wait, inserted at the tail of 
its dispatching queue, and the PPU is 
returned to dispatching. The process 
will be removed from device wait at 
the completion of the specified opei— 
ation. 

The HDV instruction will attempt to 
stop any operation actually in 
progress on the device, and will de¬ 
lete all operations previously ini¬ 
tiated which are not yet complete. 
If the I/O interface or device adapt¬ 
er are busy, so that the device can¬ 
not be signalled, the process is 
placed into device wait, inserted at 
the head of its dispatching queue, 
and the PPU is returned to dispatch¬ 
ing. The process is removed from de- 
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vice wait when the busy condition is 
cleared, and the HDV is retried when 
the process is next dispatched. This 
procedure will be repeated, if neces¬ 
sary, until the device can be sig¬ 
nalled to halt the current operation. 
When the device is halted, or if it 
was not busy to start with, the in¬ 
struction is completed by removing 
from interface control any IORB for 
the device which was the subject of a 
previous SDV, and for which the opei— 
ation has not yet been actually 
started. 

7,3 I/O Rgauast Disposition 

When a D-procass has completed the 
interpretation of the information in 
its currant space, it must terminate 
the I/O request by disposing of that 
space before another request can be 
acquired. The normal termination of 
an I/O request is by means of an END 
I/O REQUEST instruction (EIOR), 
which can, in fact, be executed at 
any time by a D-process. If EIOR is 
executed when there is no current 
space, it is treated as a null in¬ 
struction. If there is a current 
space, 

o the space is removed from I/O re¬ 
quest state and the I/O request 
count of its associated process 
is decremented by 1. If that 
process is a C-process or D-pro- 
cess waiting for completion of 
the request, it is removed from 
I/O wait dispatching condition. 

o The process state vector is al¬ 
tered so that there is no space 
currant for the D-process. 

Normal action for EIOR is to return 
the space to the custody of the re¬ 
questing process or process family, 
with the protection vector set to the 
value in effect at the time the 
request was made. However, if the 
'no return' option of the instruction 
is chosen, the space will remain in 


custody of the D-process. In can 
then be disposed of by a FREE, ENQ, 
or SGS instruction. Any attempt to 
reference the space by these instruc¬ 
tions while it is still in I/O re¬ 
quest state will cause a data 
exception. 

A D-process can also dispose of its 
current space by means of an RIO in¬ 
struction. In that case, the request 
represented by the space has been 
passed on to another device; the 
space remains in request state, and 
its relation to the requesting pro¬ 
cess is the same as if that process 
had made the request of the new de¬ 
vice rather than the original one. 

7.9 Usa of Domain Identifier 

In contrast to process models of oth¬ 
er process classes, a D-process model 
can be assigned a domain identifier. 
The domain identifier of a model, 
which can be different from the do¬ 
main identifiers assigned to pro¬ 
cesses of its family, provides a 
means of reserving devices for spe¬ 
cific use, if desired. A device is 
said to be reserved if bit 4 of field 
DMFLG of the DMDB of the process mod¬ 
el connected to the device is set to 
1. If a device is reserved for any 
domain except the common domain, I/O 
requests are accepted only from those 
processes whose domain identifier 
matches the domain identifier of the 
D-process model. A device reserved 
for the common domain is treated as 
if it were not reserved. 

The initial reservation of a device 
becomes effective as soon as a pro¬ 
cess model is connected or replaced. 

o If bit 4 of field DMFLG or the 
DMDB is zero, the device is not 
reserved. 

o If bit 4 is 1, the device is re¬ 
served for the domain to which 
the entry context space belongs. 
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If bit 3 of field DMFLG of the DMDB 
so indicates, the identifier can be 
replaced by execution of a RESERVE 
DEVICE instruction (RSRV). RSRV can 
be executed within any process which 
can replace or delete the process 
model; it becomes effective as soon 
as it is executed, whether or not a 
D-process of the family exists. 

The rules for acquisition of domain 
identifier by a D-process are similar 
to those for a C-process [Section 
5.91. 

o If bit 1 of field DMFLG of the 
DMDB is zero, the initial domain 
identifier of a D-process is the 
domain identifier of its entry 
context space. 

o If the bit is 1, the initial do¬ 
main identifer is that of the do¬ 
main for which the associated 
device is reserved, or that of 
the common domain if the device 
is not reserved. 

o If bit 2 of field DMFLG is 1, the 
initial identifier is retained 
by the process throughout its 
lifetime. If bit 2 is zero, the 
domain identifier is changed by 
execution of a NEXT instruction 
to the domain identifier of the 
space obtained from the request 
queue. 

If a device reservation is altered 
before all I/O requests for a previ¬ 
ous reservation have been completed, 
resource usage statistics may be 
logged under a different identifier 
than the one which was used to admit 
the requests. This situation is not 
considered to be an error, as reset— 
vation and resource utiliztion are 
accounted for separately. 

7.10 Termination 

A request for termination of a D-pro¬ 
cess is triggered by an END PROCESS 


instruction (END). The request can 
signify normal completion, or recog¬ 
nition of a condition for the process 
or device which precludes continua¬ 
tion. END is similar to EXIT in that 
it sets up an entry to a service 
which will complete essential proce¬ 
dures left uncompleted by the pro¬ 
cess, and will recover resources 
before actually deleting the process 
from the system. Termination service 
gets control first when the process 
is next dispatched after completion 
of the END. 

o if the process has a current 
space, termination service first 
disposes of the space as if an 
EIOR which returns the space to 
its original custody had been in¬ 
serted in the instruction stream 
prior to the END. 

o Requests which remain in the re¬ 
quest queue are deleted as if 
they, too, had been subjected to 
EIOR. When all requests have 
been deleted, the linkage con¬ 
trol stack of the process is re¬ 
moved by completing any open 
return sequences. 

o If the process has no I/O re¬ 
quests outstanding, all spaces 
which remain in its private cus¬ 
tody are deleted, and the process 
is deleted from the system. If 
there are outstanding requests, 
the process is inserted at the 
tail of its dispatching queue, 
and the PPU assigned to the pro¬ 
cess is returned to dispatching. 

If process termination is not com¬ 
pleted with the first entry, termi¬ 
nation service will continue to 
insert the process at the tail of its 
dispatching queue until it gets con¬ 
trol with all I/O requests completed; 
it will then complete termination of 
the process. If an initiation re¬ 
quest is triggered prior to com¬ 
pletion of termination, the request 
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is left in the request queue, and a 
new process is initiated at once to 
replace the terminating process. 

7.11 Exception Handling 

D-process have a fixed exception mask 
which is set to zero, so that all 
class 4 exceptions are suppressed. 
The treatment of D-process excep¬ 
tions with codes 1 through 7 is 
essentially the same as that for 
C-processes [Sections 5.13, 5.14], 
except that as a D-process cannot ex¬ 
ecute the DXM instruction, any excep¬ 
tion module must be specified with 
the process model. 

If an invalid process model system 
exception is raised because field 
DMXMD of the DMDB identifies a space 
no longer in existence, the process 
is terminated even for a class 3 ex¬ 
cept i on. 

7.12 Attachment Interfaces 

A device actually connected to an I/O 
interface is usually an adapter which 
converts the interface signals to the 
signals and formats expected by its 
devices. Adapters can be integral 
with a single device or can them¬ 
selves interface to a number of de¬ 
vices. The purpose of an adapter may 
be device control only, or it may al¬ 
ter the appearance of the interface 
to that expected by devices designed 
for other interfaces (e.g. the S/370 
channels). The only requirements on 
adapters are that they conform to the 
interface signals and protocol. 

A channel I/O interface contains 
polling, selection, and control 
lines, as well as a data bus. The 


interface electrical lines are 
passed from device to device to es¬ 
tablish a multi-drop connection. De¬ 
vices monitor the state of these 
lines by attaching them to receivers, 
and raise signals on the lines by 
connecting line drivers. An EPSILON 
channel is therefore similar to an 
S/370 channel, in that devices are 
interlocked by DC signals which are 
passed from one device to the next 
for polling, selection, and control. 

A loop I/O interface, however, is not 
interlocked by DC signals. Devices 
connected to a loop receive a contin¬ 
uous stream of signals representing 
bits organized into groups called 
frsnas. Frames contain both control 
information and data, the content and 
destination being determined by the 
frame itself of by the content of 
previous frames. Frame discipline 
for EPSILON loops is designed to min¬ 
imize the number of bits required to 
convey information on a loop. 

Every device on an EPSILON system is 
assigned a selection address which 
designates its attachment interface, 
and uniquely distinguishes it from 
all other devices connected to the 
same interface. Selection addresses 
are assigned as devices are connected 
to a system, and can have any 16-bit 
value. The relation between device 
identifier and selection address is 
available only to system microcode, 
which uses this information both to 
signal the correct device and to con¬ 
form to the proper interface proto¬ 
col. D-processes are therefore not 
required to take into account the 
kind of interface to which a device 
is attached. 
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7.13 Instruction Dascriptions 


STORE DEVICE LIST 


Principles of Operation 
The EPSILON System 


STDL R1,D2(X2,B2) <RX> 

Device identifiers are stored in successive half-words starting at the 
second operand location, up to the number of half-words specified by the value 
contained in arithmetic register Rl. Subsequently the content of the register 
is replaced by the difference between its original value and the number of de¬ 
vices connected to the system. 

Identifiers are stored in order of increasing numerical value, starting 
with the identifier of lowest value. If storing an identifier would require 
exceeding the space boundary, the instruction is terminated with condition 
code 3, and without decrementing register Rl. If the instruction is com¬ 
pleted, the condition code is set according to the value of arithmetic regi¬ 
ster Rl. 


Process Class: c,R 

Condition Code: 

0 Difference is zero 

1 Difference is negative 

2 Difference is positive 

3 Insufficient space allowed 

Exceptions: None 


STORE DEVICE DESCRIPTION 


STDDW R1,D2(B2> <RS> 

The DDL! of the device whose identifer is contained in arithmetic register 
Rl is stored at the second operand location. 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is terminated with 
conditon code 1 if register Rl does not contain the identifier of a device 
connected to the system. 

Process Class: C,R,D 

Condition Code: 

0 DDW stored 

1 Device not present 

2 

3 

Exceptions : 

Specification 
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CONNECT D-PROCESS MODEL 


CDPM R1,D2(B2> <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is suppressed with a 
data exception if arithmetic register R1 does not contain the identifier of a 
device connected to the system. The instruction is terminated with condition 
code 1 if field DMMOD of the DMDB located by the second operand does not con¬ 
tain either a null pointer or a pointer to a module M-space for which field 
DMLOC designates a valid instruction location within the space, or if field 
DMXMD does not contain either a null pointer of a pointer to a module space. 

If there is no process model connected to the device, the instruction is 
terminated with condition code 1 if field DMCTX does not contain a null point¬ 
er of a pointer to an ordinary M-space in private or family custody of the pro¬ 
cess within which the instruction is being executed. If the instruction is 
not terminated, the proposed model is connected to the device, and assigned to 
the custody of the family of the process within which the instruction is being 
executed. The instruction completion sequence is then entered. 

If a process model is already connected to the device, it is tested for 
deletion status. Deletion is allowed if the model is in custody of the family 
of the process within which the instruction is being executed or if the modal 
is in public custody. The instruction is terminated with condition code 2 if 
deletion is not allowed. If deletion is allowed, and if field DMMOD of the 
proposed new DMDB contains a null pointer, the process model data is discon¬ 
nected from the device, the entry context space is deleted if bound to the 
model, and the instruction is completed with condition coda zero. 

If field DMMOD is non-null, the DMDB data for the existing model is re¬ 
placed by the new DMDB data, and the instruction completion sequence is en¬ 
tered. Prior to replacement, the proposed entry context space is compared to 
the entry context space of the existing model. If the spaces are not the same, 
and if the space of the existing model is bound to its custody, that space is 
deleted from the system. 

The instruction completion sequence tests bit 3 of field DMFLG to deter¬ 
mine the custody of any non-null entry context space. If the bit is zero, the 
space is bound to custody of the process model; if the bit is 1, the custody of 
the space is not altered. The instruction is then completed with conditon 
coda zero. 

If the process model is deleted or replaced when there is a process of the 
family active, that process continues to exist until its termination is spe¬ 
cifically requested. 
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Process Class 1 C,R 
Condition Code: 

0 Model connected or deleted 

1 Invalid DMDB format 

2 Deletion not allowed 

3 

Exceptions= 

Specification 
Data 


CONNECT D-PROCESS MODEL INDIRECT 


CDPMI Rl, R2 <RR> 

The instruction is terminated with condition code 3 if either arithmetic 
register R1 or arithmetic register R2 do not contain the identifier of a de¬ 
vice connected to the system. 

If both registers contain valid identifiers, the instruction is termi¬ 
nated with condition code 1 if a process model is not is not connected to the 
device identified by register R2. If a model is connected with an entry con¬ 
text space which is not bound to it, the instruction is terminated with condi¬ 
tion code 1 if the space is not in private or family custody of the process 
within which the instruction is being executed. If the instruction is not 
terminated, it is then processed as if it were a CDPM referring to the device 
identified by the contents of register Rl, with a DMDB identical to that of 
the other device. 

If the instruction is completed with condition code zero, a reference is 
generated specifying that the DMDB data of the device identified by register 
Rl resides with the device identified by register R2. The reference is pre¬ 
served until execution of another instruction which connects a process model 
to the the device identified by register Rl. 

Process Class: C,R 

Condition Code: 

0 Model connected or deleted 

1 Invalid DMDB format 

2 Deletion not allowed 

3 Device not present 

Exceptions: None 
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STORE DEVICE STATUS 


STDS R1,D2CB2) <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is terminated with 
condition code 2 if arithmetic register R1 does not contain a device identifi¬ 
er, and with condition coda 1 if a process model is not connected to the de¬ 
vice. 

If the device has a process model connected, the DMDB data for the model 
is stored into successive words, starting at the second operand location. The 
instruction is then completed with condition code zero. 

Process Class: C,R 

Condition Code: 

0 DMDB stored 

1 Process model not connected 

2 Device not present 

3 

Exceptions : 

Specification 


REQUEST INPUT/OUTPUT 


RIO Ml,R2 <RR> 

The instruction is suppressed with a data exception if pointer register R2 
does not identify an ordinary M-space, and with an access exception if the 
space is not in private or family custody of the process within which the 
instruction is being executed. It is terminated with condition code 3 if 
arithmetic register R2 does not contain the identifier of a device connected 
to the system, with condition code 2 if the device is inaccessible or suspen¬ 
ded, and with condition code 1 if there is no process model connected to the 
device. If the instruction is being executed within a D-process, it will also 
be terminated with condition code 3 if register R1 contains the identifier of 
the device associated with the process. 

If the instruction is not suppressed or terminated, the reference count of 
the space is decremented by 1. The high order bit of mask field Ml is examined 
to determine if the space is to be placed into request state. If the bit is 
zero, the retained status of pointer register R2 is set to ’space not avail¬ 
able', and the space is placed into request state by recording the protection 
vector, the requesting process, and the device on which the request was made. 
If the space was already in request state, the device is recorded without al¬ 
tering the other recorded data. If the bit is 1, a null pointer is loaded into 
pointer register R2, and request state data is not recorded. 

A null pointer is then loaded into any other pointer register of the pro¬ 
cess which contains a pointer to the space, and the reference count is decre- 
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mented by 1 for each pointer loaded. If the reference count coes not become 
zero* the space is placed in system custody, the request is recorded, and the 
instruction completion sequence is entered. The space will be placed into the 
request queue for the device whenever the count subsequently becomes zero. 

If the reference count is zero, the custody flag is turned off, and the 
space is inserted at the bottom of the request queue for the device, bound to 
its custody. If the request queue was empty at the time of insertion, an ini¬ 
tiation request is triggered designating the process model connected to the 
device. The completion sequence is then carried out. 

If the instruction is being executed within an R-process, it is completed 
by setting the condition code to zero. If the process is a C-process or D-pro- 
cess, if the space was placed onto request state, and if bit 1 of mask field Ml 
is zero, the process is placed into I/O wait dispatching condition. The I/O 
wait condition is not generated if bit 1 is 1, or if request state is sup¬ 
pressed. The instruction is then completed with condition code zero. 

If an I/O wait condition is generated, the processing mechanism assigned 
to the process is returned to dispatching. The wait condition will be removed 
when the space is removed from request state. In the case of a D-process, com¬ 
pletion also includes inserting the process at the tail of its dispatching 
queue. 

Process Class: C,R,D 
Modal 


Condition Code: 

0 Request accepted 

1 Process model not connected 

2 Device not available 

5 Device not present 

Exceptions : 

Access 

Data 


TEST INPUT/OUTPUT 


TIO R2 <RR> 

The space identified by pointer register R2 is examined for request state. 
If tiie space is not in request state and not in custody of the process or pro¬ 
cess family within which the instruction is being executed, the instruction is 
completed with condition code 3, otherwise it is completed with condition code 
zero. 

If the space is in request state, and if it is the current space of the 
process associated with the device on which the request was made, condition 
code 1 is set and the completion sequence is entered. If the space is not the 
current space, condition coda 2 is set. 

If the instruction is being executed within an R-process, it is completed 
as soon as the condition code is set. If the process is a C-process or D-pro¬ 
cess, the process is placed into I/O wait dispatching condition, and the pro¬ 
cessing mechanism assigned to the process is returned to dispatching. The 
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wait will be removed when the space identified by pointer register R2 is 
removed from request state. In the case of a D-procsss, completion also in¬ 
cludes inserting the process at the tail of its dispatching queue. 

Process Class: C,R,D 
Modal 


Condition Code: 

0 Request complete 

1 Request in progress 

2 Request enqueued 

3 Request not found 

Exceptions: None 


NEXT REQUEST 


NEXT Ml, R2 <RR> 

If the process within which the instruction is being executed has a cui— 
rent space, the instruction is terminated with condition code 2. If the re¬ 
quest queue for the device associated with the process is empty, and if the 
high-order bit of mask field Ml is zero, process termination is requested. If 
the bit is not zero, the instruction is terminated with condition code 1. 

If the request queue is not empty, the item at the head of the queue is re¬ 
moved, a pointer to it is loaded into pointer register R2, its custody flag is 
turned on, and its reference count is set to 1. The space is placed into the 
private custody of the process, and if it is in request state, it becomes the 
current space of the process. 

Bit 2 of field DMFLG of the DMDB for the process model of the family is ex¬ 
amined to determine treatment of the domain identifier of the process. If the 
bit is zero, the domain identifier of the process is replaced by the domain 
identifier of the space just removed from the request queue. If the bit is 1, 
the domain identifier of the process is not altered. The instruction is then 
completed with condition code zero. 

If the instruction is terminated, the process is inserted at the tail of 
its dispatching queue, and the PPU is returned to dispatching. The condition 
code return will become effective when the process is next dispatched. 

Process Class 1 D 

Condition Code 1 

0 Request obtained 

1 Request queue empty 

2 Space still current 

3 

Exceptions: None 
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START DEVICE 


SDV M1,D2(X2,B2) <RX> 

The instruction is suppressed with a specification exception if the second 
operand does not locate a word boundary. It is terminated with condition code 
3 if the device associated with the process is inacessible, suspended, not 
ready, or requires interventi on. 

Lf the space identified by field SPACE of the IORB located by the second 
operand is not an ordinary M-spaca, the instruction is terminated with condi¬ 
tion code 2. If the space is not in custody of the process and is not in re¬ 
quest state, the instruction is terminated with condition code 1. If the 
space is not in custody of the process but is in request state, the access to 
the space of the requesting process is tested for validity. If the command in 
field CMSTG of the IORB is a READ or SENSE, the process must have write access 
to be valid. If the command is WRITE or CONTROL the process must have read ac¬ 
cess to be valid. The instruction is terminated with condition coda 1 if the 
access is not valid. 

If the access is valid, a signal is sent to the I/O interface requesting 
acceptance of the IORB for the device with which the process is associated. 
If the interface or device is busy, the process is placed into device wait 
condition, inserted at the head of its dispatching queue, and the PPL) returned 
to dispatching. The wait will be removed when the busy condition which caused 
it is removed, and the instruction will be retried whan the process next gets 
dispatched. 

If the IORB is accepted, the process is inserted at the tail of its dis¬ 
patching queue. If the high-order bit of mask field Ml is zero, the process is 
also placed into device wait dispatching condition. Condition code zero is 
then set and the instruction is completed by returning the PPU to dispatching. 

The mask field is transmitted to the I/O interface with the location of 
the IORB, for use by the operation completion sequence. If bit 1 of the field 
is zero and the operation is completed with device error, sense data will be 
obtained from the device and stored into field SENSE of the IORB. Up to eight 
bytes of data will be stored, depending on the response of the device to a 
SENSE command with modifier bits all zero. If bit 1 is not zero, sense data 
will not be obtained. If bit 2 is zero, the identifier of the device will be 
stored into field DVID of the IORB, otherwise it will not. The remaining bits 
of the mask field are not examined. 

Process Class: D 

Condition Code: 

0 Operation accepted 

1 Invalid access 

2 Invalid space 

3 Device not available 

Exceptions: 

Specification 
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WAIT DEVICE 


WDV D2(X2,B2) <RX> 

The instruction is suppressed with a specification exception if the second 
operand does not locate a word boundary. It is terminated with condition code 
3 if the device associated with the process is inaccessible, suspended, not 
ready, or requires intervention. 

The IORB located by the second operand is tested for acceptance by the I/O 
interface. If acceptance is not recorded and bit zero of field IOST is set to 
1, the instruction is completed with condition code zero. If the bit it zero, 
the instruciton is terminated with condition code 1. 

If the IORB acceptance is still recorded, the process is placed into de¬ 
vice wait dispatching condition and inserted at the tail of its dispatching 
queue. Condition coda zero is set, and the PPU is returned to dispatching. 
The process will be removed from device wait when the operation contained in 
the IORB located by the second operand is completed. 

Process Class 1 D 

Condition Code 1 

0 Operation complete 

1 Operation unknown 

2 

3 Device not available 

Exceptions • 

Specification 


HALT DEVICE 


HDV R2 <RR> 

The instruction is terminated with condition code 3 if the device associ¬ 
ated with the process is inaccessible, suspended, not ready, or requires 
intervention. 

If the device is available, a signal is sent to the I/O interface request¬ 
ing the device be halted. If the interface or device adapter are busy, the 
process is placed in device wait dispatching conditon, inserted at the head of 
its dispatching queue, and the PPU returned to dispatching. The wait will be 
removed when the busy condition which caused it is removed, and the instruc¬ 
tion will be retried when the process is next dispatched. 

If the signal is accepted, the device is signalled to halt. If the device 
was busy with an operation contained in an IORB, the location of the IORB is 
placed in general register R2 and condiion code zero is set. If it was not en¬ 
gaged in an operation contained in an IORB, general register R2 is not al¬ 
tered, and condition code 1 is set. 

The instruction is then completed by requesting cancellation by the I/O 
interface of any IORB for the device still recorded as accepted. Bits zero 
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and 3 of field IOST are set to 1 for cancelled IORB. 

Process Class 1 D 

Condition Code: 

0 IORB location loaded 

1 IORB location not loaded 

2 

3 Device not available 
Exceptions: None 
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SET DEVICE STATUS 


SDS Ml,M2 <RR> 

The status of the device associated with the process is set according to 
the bits of the mask fields. 

Mask field M2 indicates which conditions are to be altered. The bits coi— 
respond in high-to-low order to the conditions inaccessible, suspended, 
intervention required, and not ready. If a bit is zero the correspondi ng con¬ 
dition is to remain as is; it a bit is 1 the condition is to be set to the val¬ 
ue indicated by mask field Ml. 

The bits in mask field Ml correspond to the conditions in the same order. 
A bit specifies the condition to be on (set) if its value is 1, and to be off 
(reset) if its value is zero. 

Process Class 1 D 

Condition Code: Unchanged 

Exceptions: None 


END I/O REQUEST 


EIOR Ml <RR> 

If the process has no space current, the instruction is terminated with 
condition code 2. If there is a current space, it is removed from request 
state and the I/O request count of the associated process is decremented by 1. 
If that process is a C-process or D-process in I/O wait dispatching condition, 
it is removed from the wait condition. 

If bit zero of mask field Ml is zero, the space is returned to the custody 
of the requesting process or process family, with the protection vector set to 
the value preserved when the space was placed into request state. The pointer 
registers of the process within which the instruction is being executed are 
examined. If a register contains a pointer to the space, it is loaded with the 
null pointer. The reference count of the space is decremented by 1 for every 
null pointer loaded. Condition code zero is set for completion. 
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If bit zero of mask field Ml is not zero, the space is left in custody of 
the process executing the instruction, and condition code 1 is set for com- 
pletion. 

The process is then placed in the condtion of having no space current, and 
the instruction is completed with the condtion code previously set. 

Process Class: D 

Condition Code: 

0 Space returned 

1 Space retained 

2 No space was current 

3 

Exceptions: None 


RESERVE DEVICE 


RSRV R1,R2 <RR> 

The instruction is terminated with condition code 3 if arithmetic register 
R1 does not identify a device connected to the system, or if a process model is 
not connected to the device. It is suppressed with a data exception if arith¬ 
metic register R2 does not contain a valid device identifier. 

If a process model is connected, the instruction is terminated with condi¬ 
tion code 2 if the model is not in public custody or in custody of the process 
or process family within which the instruction is being executed. It is tei— 
minated with condition code 1 if custody is acceptable but bit 5 of field 
DMFLG of the DMDB indicates that the device cannot be reserved. 

If the device can be reserved, the process model is assigned the domain 
identifier contained in arithmetic register R2. The instruction is then com¬ 
pleted with condition code zero. 

Process Class: c,R 

Condition Code: 

0 Device reserved 

1 Reservation not allowed 

2 Invalid process model reference 

3 Process model not connected 

Except ions 1 

Data 
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END PROCESS 


END I <RR> 

Termination is requested for the process within which the instruction is 
being executed. The byte of immediate data is stored in the state vector, the 
process is inserted at the tail of its dispatching queue, and the instruction 
is completed by returning the PPU assigned to the process to dispatching. 

Termination is completed at some later time by system microcode [Section 
7.101. 


Process Class: D 
Condition Code: Unchanged 
Exceptions: None 
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3.0 GENERAL INSTRUCTIONS 

Most of the EPSILON system arithme¬ 
tic/ logical, and branching instruc¬ 
tions have been adopted from the 
S/360. and S/370 non-pr i vi leged 
instruction sets, with only minor 
changes of interpretation. There¬ 
fore, the following conventions have 
been employed as a means of minimiz¬ 
ing the amount of material necessary 
to describe these instructions. 

o The instructions are organized 
into groups related by class of 
function or by some charactei— 
istic of interpretation. 

o Each group is introduced by a 
general discussion of the opei— 
and field interpretation for the 
instruction formats which apply 
to the group, and a description 
of operand data formats. This 
discussion is followed by a table 
listing all instructions of the 
group. 

o If the column in the table headed 
'description* contains an entry 
which refers to POP360 or POP370, 
the corresponding instruction 
behaves exactly as described by 
the reference, apart from any 
changes of interpretation which 
apply to the whole group. In 
that case, no further descrip¬ 
tion of the instruction appears 
in this document. If the column 
entry is the word 'new', the in¬ 
struction is new, while if the 
entry is blank the instruction 
differs from the S/360 or S/370 
instruction in some 

non-superficial way. In either 
case, a full description of the 
instruction follows the table. 

The table for each group also lists 
the instruction mnemonic and process 
class. The operation codes, which 
are not listed, are the same as the 


codes for the corresponding S/360 or 
S/370 instruction, if there is one. 
Operation codes for new instructions 
have not yet been selected. 

E.1 Fixed-Point Arithmetic 

Fixed-point arithmetic is essential¬ 
ly the same as S/360 and S/370. Num¬ 
bers are represented as integers in 
two's-complement form, either 16, 
32, or 64 bits in extent. The first 
bit of a number field is considered 
to be a sign bit, except that for in¬ 
structions with the word LOGICAL in 
their name the entire field is 
treated as an unsigned integer. 

Fixed-point instructions use the RR, 
RX, and RS formats. In these foi— 
mats, whose operand fields are re¬ 
presented in symbolic assembler 
notation as 

R1,R2 

R1,D2(X2,B2) 

R1,R3,D2(B2) 

the first and third operands always 
designate an arithmetic register. 
The second operand may specify a reg- 
ister or a location, depending on the 
format and instruction. 

In the RR format, the second operand 
field, R2, designates an arithmetic 
register which contains the actual 
operand data. In the RX format, the 
B2 field designates a general regi¬ 
ster whose contents, together with 
the displacement D2 and the contents 
of the arithmetic register desig¬ 
nated by X2, are combined using the 
rules of Section 2.8 to form the 
M-space address of the operand data. 
In the RS format, the B2 field of the 
instructions LOAD MULTIPLE and STORE 
MULTIPLE designates a general regi¬ 
ster which is used to form the second 
operand address as in the RX format. 
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except that indexing cannot occur. 
In the shift instructions, the B2 
field designates an arithmetic regi¬ 
ster whose contents are added to the 
D2 field to form a sum which speci¬ 
fies the amount of the shift. 

Instructions can designate the same 
register in all operand fields with 


results consistent with using dif¬ 
ferent registers, as address compu¬ 
tation is completed before 
instruction execution. Instruction 
results replace the first (and third) 
operands, except for the store 
instructions for which the result re¬ 
places the second operand. 


Figure 8.1 

Fixed-Point Arithmetic Instructions 


Name 

ADD 

ADD 

ADD HALFWORD 
ADD LOGICAL 
ADD LOGICAL 
COMPARE 
COMPARE 

COMPARE HALFWORD 

COMPARE LOGICAL 

COMPARE LOGICAL 

DIVIDE 

DIVIDE 

LOAD 

LOAD 

LOAD AND TEST 
LOAD AND TEST 
LOAD COMPLEMENT 
LOAD HALFWORD 
LOAD MULTIPLE 
LOAD NEGATIVE 
LOAD POSITIVE 
MULTIPLY 
MULTIPLY 

MULTIPLY HALFWORD 

SHIFT LEFT DOUBLE 

SHIFT LEFT DOUBLE LOGICAL 

SHIFT LEFT SINGLE 

SHIFT LEFT SINGLE LOGICAL 

SHIFT RIGHT DOUBLE 

SHIFT RIGHT DOUBLE LOGICAL 

SHIFT RIGHT SINGLE 

SHIFT RIGHT SINGLE LOGICAL 

STORE 

STORE HALFWORD 
STORE MULTIPLE 
SUBTRACT 
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Symbol 

Type 

Class 

Description 

AR 

RR 

C, R, D 

POP370 : 122 

A 

RX 

C, R 

POP370:122 

AH 

RX 

C, R 

POP37 0 : 122 

ALR 

RR 

C, R, D 

POP370:122 

AL 

RX 

C, R 

POP370•122 

CR 

RR 

C, R, D 

POP370 = 126 

C 

RX 

C, R 

P0P37 0 •126 

CH 

RX 

C, R 

P0P370 = 128 

CLR 

RR 

C, R, D 

POP 37 0:128 

CL 

RX 

C, R 

POP370=128 

DR 

RR 

o 

✓0 

u 

POP370■131 

D 

RX 

C, R 

POP370:131 

LR 

RR 

C, R, D 

POP370:134 

L 

RX 

C, R, D 

P0P37 0 •' 134 

LTR 

RR 

C, R, D 

POP370:134 

LT 

RX 

C, R, D 

New 

LCR 

RR 

C, R, D 

POP370:134 

LH 

RX 

C, R 

P0P370 '■ 135 

LM 

RS 

C, R, D 

POP 37 0 : 135 

LNR 

RR 

C, R , D 

POP370 = 135 

LPR 

RR 

C, R, D 

P 0 P 3 7 0 •' 135 

MR 

RR 

C, R, D 

POP370:139 

M 

RX 

C, R 

POP370:139 

MH 

RX 

C, R 

P0P37 0 : 14 0 

SLDA 

RS 

C, R, D 

P0P37 0 : 141 

SLDL 

RS 

C, R, D 

POP370:142 

SLA 

RS 

C, R, D 

POP370=142 

SLL 

RS 

C, R, D 

P0P37Q = 143 

SRDA 

RS 

C, R , D 

POP370:143 

SRDL 

RS 

C, R , D 

POP370:143 

SRA 

RS 

C, R, D 

POP370:144 

SRL 

RS 

C,R, D 

POP370 :144 

ST 

RX 

C, R, D 

P0P37 0 ■ 144 

STH 

RX 

C, R 

P0P37 0 • 146 

STM 

RS 

C, R , D 

POP370:146 

SR 

RR 

C, R, D 

POP370 : 146 


General Instructions 




Principles of Operation 
The EPSILON System 


Versi on 1.0 
15 June 1976 


SUBTRACT 


S 

RX 

C, R 

POP370:146 

SUBTRACT 

HALFWORD 

SH 

RX 

C, R 

POP370:147 

SUBTRACT 

LOGICAL 

SLR 

RR 

C r R r D 

POP370:147 

SUBTRACT 

LOGICAL 

SL 

RX 

C,R 

POP370:147 


LOAD AND TEST 


LT R1,D2(X2,B2) <RX> 

The second operand is placed unchanged into arithmetic register Rl, and 
the sign and magnitude of the result determine the condition code. 

Process Class: C,R,D 

Condition Code : 

0 Result is zero 

1 Result is less than zero 

2 Result is greater than zero 

3 

Exceptions : 

Access 


8.2 Logical Operations 


Logical operations manipulate data 
as uniform bit fields of fixed 
length, or as a variable length 
string of character bytes. Fixed 
length data fields consist of a sin¬ 
gle or double word, or a single chai— 
acter. As instruction operands, they 
are resident in arithmetic regi¬ 
sters, or an M-space, or are ex¬ 
tracted from a field in the 
instruction. Variable length data 
fields always reside in an M-space, 
and are acted upon by instructions 
which relate them to some other vari¬ 
able length field, not necessarily in 
the same space. 


The logical operation instructions 
use all five instruction formats, RR, 
RX, RS, SI, and SS. In the RR, RX, 
and RS formats, the first operand 
field always designates an arithme¬ 
tic register, as does the second op¬ 
erand field of the RR format. In the 
RX and RS formats, the B2 field des¬ 


ignates a general register whose 
contnents, together with the dis¬ 
placement D2 and the contents of the 
arithmetic register designated by X2 
(if present), are combined using the 
rules of Section 2.8 to form the 
M-space address of the second operand 
data. In the RS format, the R3 field 
is used as a mask to identify those 
bytes of the first operand data actu¬ 
ally acted upon by the instruction. 

For the SI and SS formats, the opei— 
and fields are represented in symbol¬ 
ic assembler notation as 

D1CB1), 12 

D1(L,B1),D2(B2) 

The B1 field designates a general 
register whose contents are combined 
with the displacement D1 to form the 
M-space location of the first operand 
data. In the SS format, the L field 
is a byte whose value specifies the 



Chapter 8 


118 


General Instructions 




Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


length of the operand data fields, ferent registers, as address compu- 
and the B2 field designates a general tation is completed before 
register whose contents are combined instruction execution. In the SS 
with the displacement D2 to form the format instructions, the operand da- 


M-space location of the second opei— 

ta fields 

can overlap, i 

with results 

and data. In the SI format, the 12 

consistent 

with handling 

one byte at 

field is a byte which itself is the 

a time, starting 

at the 

address of 

second operand data. 

the first byte of the first operand. 
Results replace the the first opei— 

Instructions can designate the same 

and, except for 

store 

i nstructions 

register in all operand fields with 
results consistent with using dif- 

for which the result replaces the 
second operand. 

Name 

Symbol 

IlLR.e 

Class 

Description 

AND 

NR 

RR 

C, R, D 

P0P37 0 = 123 

AND 

N 

RX 

C, R 

POP370:123 

AND CHARACTER 

NC 

SS 

C 

POP370 = 123 

AND IMMEDIATE 

NI 

SI 

C, R, D 

POP370 = 123 

COMPARE LOGICAL CHARACTER 

CLC 

SS 

C 

POP370:128 

COMPARE LOGICAL IMMEDIATE 

COMPARE LOGICAL 

CLI 

SI 

C, R, D 

POP370:128 

CHARACTERS UNDER MASK 

CLM 

RS 

C, R 

P0P370 •' 129 

EXCLUSIVE OR 

XR 

RR 

C, R, D 

POP370 = 131 

EXCLUSIVE OR 

X 

RX 

C, R 

P0P370 '• 131 

EXCLUSIVE OR CHARACTER 

xc 

SS 

C 

POP370 = 131 

EXCLUSIVE OR IMMEDIATE 

XI 

SI 

C, R, D 

POP37 0 = 131 

INSERT CHARACTER 

IC 

RX 

C, R, D 

POP370 •• 133 

INSERT CHARACTERS UNDER MASK 

I CM 

RS 

C, R 

POP370:133 

MOVE CHARACTER 

MVC 

SS 

C 

P0P37 0 : 136 

MOVE IMMEDIATE 

MV I 

SI 

C, R, D 

P0P370:136 

OR 

OR 

RR 

C, R, D 

POP370 : 140 

OR 

0 

RX 

C, R 

POP370 : 140 

OR CHARACTER 

OC 

SS 

C 

POP370 •• 140 

OR IMMEDIATE 

01 

SI 

C, R, D 

POP370 •• 140 

STORE CHARACTER 

STC 

RX 

C, R, D 

P0P370 s145 

STORE CHARACTERS UNDER MASK 

STCM 

RS 

C, R 

POP370 : 145 

TEST AND SET 

TS 

SI 

C, R , D 

POP370:148 

TEST UNDER MASK 

TM 

SI 

C, R, D 

POP370 : 149 

TRANSLATE 

TR 

SS 

C 

P0P370 : 149 

TRANSLATE AND TEST 

TRT 

SS 

C 

POP370 : 149 


Figure 8.2 

Logical Operation Instructions 


B.3 Branching 

Branching instructions alter the ex¬ 
ecution sequence of a process by gen¬ 
erating an address from which the 
next instruction will be fetched if 
the branch is successful. The branch 
address is always computed relative 


to the M-space from which the branch 
instruction itself was fetched, so 
that branching cannot be used for 
linkage to other modules [Section 
5.7]. This local reference con¬ 
vention is also applied to the EXE- 
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CUTE and LOAD ADDRESS instructions. 

The instructions use the RR, RX, and 
RS formats, in which the first opei— 
and field, Rl, designates an arithme¬ 
tic register, except in the 
conditional branch instructions 
where it is a mask field which speci¬ 
fies branch conditions. In the RX 
and RS formats, the B2 field desig¬ 
nates an arithmetic register whose 
contents are added to the displace¬ 
ment D2 and the contents of the 
arithmetic register designated by X2 
(if present), to compute a location 
value. This value is combined with 
the identfier of the space from which 
the instruction was fetched to form 

Name 


the address of the second operand da¬ 
ta, or the new value of the process 
instruction counter on a successful 
branch. In the RS format, the R3 
field designates a pair of arithmetic 
registers which are used to determine 
when branching is to occur. 

An instruction can designate the same 
register for address modification 
and operand specification. The regi¬ 
sters designated by an instruction 
are used first for operand fetch 
address computation, second for 
arithmetic computation, and finally 
for branch address computation. Re¬ 
sults, if any, replace the first op¬ 
erand . 

Svmbo1 Type Class Description 


BRANCH 

AND 

LINK 

BALR 

RR 

C, R 


BRANCH 

AND 

LINK 

BAL 

RX 

C, R, D 


BRANCH 

ON 

CONDITION 

BCR 

RR 

C, R 

POP370:124 

BRANCH 

ON 

CONDITION 

BC 

RX 

C,R,D 

POP370:124 

BRANCH 

ON 

COUNT 

BCTR 

RR 

C, R 

POP370:125 

BRANCH 

ON 

COUNT 

BCT 

RX 

C, R, D 

POP370:125 

BRANCH 

ON 

INDEX HIGH 

EXH 

RS 

C, R 

POP370:125 

BRANCH 

ON 

INDEX LOW OR EQUAL 

BXLE 

RS 

C, R 

POP370:125 

EXECUTE 


EX 

RX 

C, R, D 

POP370:132 

LOAD ADDRESS 

LA 

RX 

C, R, D 

POP370 = 134 


Figure 8.3 

Local Reference Instructions 


BRANCH AND LINK 


BALR Rl,R2 <RR> 

BAL R1,D2(X2,B2) <RX> 


The second word of the current process instruction counter [Figure 5.2] is 
loaded as link information into arithmetic register Rl. Subsequently, the 
LCUR field of the counter is replaced by the branch address. 

In the RX format, the second operand location is used as the branch ad¬ 
dress. In the RR format, the contents of bit positions 8-31 of arithmetic 
register R2 are used as the branch address. However, when the R2 field is ze¬ 
ro, the branch address is set equal to the link address and no branching oc¬ 
curs. 

The branch address is always computed before the link information is 
loaded. 
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Long operands are character strings 
ranging in length from nero bytes to 
16,777,216 bytes. The instructions 
which manipulate these strings use 
the RR and RX formats, in which each 
R-field designates both a general 
register and a separate arithmetic 
register as a means of specifying a 
long operand. The general register, 
which must have an even value as its 
designation, is used by itself to 
form the M-space address of the long 
operand data field. The correspond¬ 
ing arithmetic register has the next 


odd value as its implied designation; 
its contents specify the length of 
the operand data. 

The operands need not reside in the 
same M-space. However, if they do, 
and if the fields overlap, the re¬ 
sults are consistent with handling 
the fields one byte at a time, start¬ 
ing at the address of the first byte 
of each field and proceeding in byte 
sequence order. Result data fields, 
if any, replace the first operand. 


Name 

Symbol 


Class 

Description 

COMPARE LOGICAL LONG 

CLCL 

RR 

C , R, D 


MOVE LONG 

MVCL 

RR 

C, R, D 


TRANSLATE 

TRL 

RX 

C, R, D 

New 

TRANSLATE AND TEST 

TRTL 

RX 

C, R, D 

New 


Figure 8.4 

Long Operand Instructions 


COMPARE LOGICAL LONG 


CLCL R1,R2 <RR> 

The first operand is compared with the second operand and the result is 
indicated in the condition code. 

The address of the first byte of the first operand is generated from the 
contents of general register Rl, and the address of the first byte of the sec¬ 
ond operand is generated from the contents of general register R2. The number 
of bytes in each operand field is specified by the contents of bits 8-31 of the 
arithmetic registers designated by the values 1+R1 and 1 + R2, respectively. 
The contents of bit positions 0-7 of these registers are ignored. 

The comparison is performed with the operands considered as a string of 
bytes representing unsigned binary integers. The comparison starts at the 
first byte of each field and proceeds in byte sequential order. The instruc¬ 
tion is completed as soon as inequality is detected or the end of the shortest 
operand is reached. An operand of zero length compares equal with an operand 
of any length. 
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At completion, the length registers 1 + R1 and 1+R2 are decremented by the 
number of bytes compared, arithmetic registers R1 and R2 are incremented by 
the same value, and the condition code is set to reflect the result of the com¬ 
parison. Bit positions 0-7 of the arithmetic registars remain unchanged. 

The instruction is suppressed with a specification exception if either op¬ 
erand field does not contain an even value. It is terminated with an address¬ 
ing exception if an address is generated during the course of comparison which 
lies outside a space containing one of th.e operands. 

Process Class 1 C,R,D 

Condition Code 1 

0 Operands are equal 

1 First operand is low 

2 First operand is high 

3 

Exceptions: 

Access 

Addressing 

Specification 
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MOVE LONG 


MVCL R1,R2 <RR> 

The second operand is placed into the first operand location, except that 
overlapping of operand locations may affect the final contents of the first 
operand location. 

The address of the first byte of the first operand is generated from the 
contents of general register Rl, and the address of the first byte of the sec¬ 
ond operand is generated from the contents of general register R2. The number 
of bytes in each operand field is specified by the contents of bits 8-31 of the 
arithmetic registers designated by the values 1+R1 and 1+R2, respectively. 
Bits 0-7 of these registers are ignored. 

The movement starts at the first byte of each field and proceeds 
byte-by-byte in byte sequential order. The instruction is completed when the 
number of bytes corresponding to the shortest operand field have been trans¬ 
ferred. At completion, the length registers 1+R1 and 1+R2 are decremented by 
the number of bytes moved, and arithmetic registers Rl and R2 are incremented 
by the same value. Bit positions 0-7 of these registers remain unchanged. 

The instruction is suppressed with a specification exception if either op¬ 
erand field does not contain an even value. It is terminated with an address¬ 
ing exception if an address is generated during the course of movement which 
lies outside a space containing one of the operands. 
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Process Class: C,R,D 

Condition Code: 

0 Fields of equal length 

1 First operand shorter than second 

2 First operand longer than second 

3 

Exceptions : 

Access 
Addressing 
Specification 
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TRANSLATE 


TRL R1,D2(X2,B2) <RX> 

The bytes of the first operand are used as arguments to reference the list 
located by the second operand address. Each function byte selected from the 
list replaces the corresponding argument in the first operand. 

The address of the first byte of the first operand is generated from the 
contents of general register Rl, and the number of bytes in the field is spec¬ 
ified by the contents of bits 8-31 of the arithmetic register designated by 
1 + R1. The bytes of the first operand are selected one by one for translation, 
starting at the first byte and proceeding in byte sequential order. Each 
argument byte is added to the initial second operand address using the rules 
for address arithmetic, with the argument byte treated as an eight-bit un¬ 
signed integer. The sum forms the address of the function byte, which then 
replaces the original argument byte. 

The instruction is completed when the first operand field has been com¬ 
pletely replaced. At completion, bits 8-31 of the length register 1+R1 are 
zero, and arithmetic register Rl is incremented by the length of the operand. 
Bits 0-7 of these registers remain unchanged. The second operand is not al¬ 
tered unless a field overlap occurs. In that case, the result is the same as 
if each r4sult byte had been stored immediately after the corresponding func¬ 
tion byte was fetched. 

The instruction is suppressed with a specification exception if the Rl 
field does not contain an even value. It is terminated with an addressing ex¬ 
ception if an address is generated during the course of translation which lies 
outside a space containg one of the operands. 

Process Class: C,R,D 

Condition Code: Unchanged 

Exceptions : 

Access 
Addressing 
Specification 
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TRANSLATE AND TEST 


TRTL R1,D2(X2,B2) <RX> 

The bytes of the first operand are used as arguments to reference the list 
located by the second operand address. Each function byte selected from the 
list is used to determine the continuation of the instruction. If the func¬ 
tion byte is zero, the instruction proceeds by fetching and translating the 
next argument byte. If the function byte is non-zero, the instruction is com¬ 
pleted. 

The address of the first byte of the first operand is generated from the 
contents of general register Rl, and the number of bytes in the operand is 
specified by the contents of bits 8-31 of the arithmetic register designated 
by 1+R1. The bytes of the first operand are selected one by one for trans¬ 
lation, starting at the first byte and proceeding in byte sequential order. 
Each argument byte is added to the intial second operand address using the 
rules for address arithmetic, with the argument byte treated as an unsigned 
eight-bit integer. The sum is used as the address of the function byte. 

When the instruction is completed, bits 8-31 of the length register 1+R1 
are decremented by the number of bytes translated before a non-zero function 
byte was found, and arithmetic register Rl is incremented by the same value. 
Bits 0-7 of register Rl are unchanged. If the instruction was completed as a 
result of finding a non-zero function byte, that byte is inserted into bits 
0-7 of register 1+R1, otherwise those bits of the register are unchanged. The 
condition code is set to reflect the cause of completion. 

The instruction is suppressed with a specification exception if the Rl 
field does not contain an even value. It is terminated with an addressing ex¬ 
ception if an address is generated during the course of translation which lies 
outside a space containing one of the operands. 

Process Class 1 C,R,D 


Condition Code : 

0 All function bytes zero 

1 Non-zero function byte found 

2 
3 

Except ions: 

Access 
Addressing 
Specification 

8.5 Decimal Faatura 

A decimal feature instruction set can 
be installed on any EPSILON system. 
Decimal instructions provide arith¬ 
metic, shifting, and editing opei— 
ations on data in the S/360 packed 
and zoned decimal formats 


[POP360=35]. The instructions use 
the SS and RX formats. The operand 
fields in these formats follow the 
rules described for the logical opei— 
ation instructions [Section 8.21. 
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Except for the conversion instruc- structions can be executed only with- 
tions, CONVERT TO BINARY and CONVERT in C-processes. 

TO DECIMAL, the decimal feature in- 


Name 

Symbol 

Type 

Class 

Description 

ADD DECIMAL 

AP 

SS 

c 

POP370:153 

COMPARE DECIMAL 

CP 

SS 

c 

P0P37 0■154 

CONVERT TO BINARY 

CVB 

RX 

C, R 

POP370 :130 

CONVERT TO DECIMAL 

CVD 

RX 

C, R 

POP370:131 

DIVIDE DECIMAL 

DP 

SS 

C 

POP370:154 

EDIT 

ED 

SS 

C 

POP370:155 

EDIT AND MARK 

EDMK 

SS 

C 

POP370:158 

MOVE NUMERICS 

MVN 

SS 

C 

POP 37 0:138 

MOVE WITH OFFSET 

MVO 

SS 

C 

POP370:139 

MOVE ZONES 

MVZ 

SS 

c 

POP370 •• 139 

MULTIPLY DECIMAL 

MP 

SS 

c 

POP370 = 158 

PACK 

PACK 

SS 

c 

POP370■141 

SHIFT AND ROUND DECIMAL 

SRP 

SS 

c 

P0P37 0 : 158 

SUBTRACT DECIMAL 

SP 

SS 

c 

POP 37 0 = 159 

UNPACK 

UNPK 

SS 

c 

POP370:150 

ZERO AND ADD 

ZAP 

SS 

c 

POP370:160 


Figure 8.5 

Decimal Instructions 


8.6 Floating-Point Features 


Two floating-point feature instruc¬ 
tion sets can be installed on any 
EPSILON system. The basic floating¬ 
point instructions operate on data in 
the S/360 short and long floating¬ 
point number formats [POP360=41]. 
The extended floating-point instruc¬ 
tions operate on data in the S/370 
extended floating-point number foi— 
mat CPOP370=162]. The extended 
floating-point feature can be in¬ 
stalled only if the basic feature is 
also installed. 

Floating-point instructions can be 
executed only within C-processes. If 
the basic featuure is installed, the 
state vector of all C-processes is 
enlarged to include four 64-bit 
floating-point registers, designated 
by the numbers 0, 2, 4, and 6. These 
registers are the referents of the 


first operand field of all floating¬ 
point instructions, and also of the 
second operand field of the RR format 
instructions. A specification 
exception will occur if values other 
than 0, 2, 4, or 6 are used to desig¬ 
nate the registers in the basic in¬ 
structions, or if values other than 0 
or 4 are used in the extended in¬ 
structions. In the RX format, the B2 
field designates a general register 
whose contents, together with the 
displacement D2 and the contents of 
the arithmetic register designated 
by X2, are combined using the rules 
of Section 2.8 to form the M-space 
location of the second operand data. 

Number representation, guard digit, 
an normalization follow the rules and 
behavior patterns of S/370 
[POP370=163-164]. 
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Name 

Svmbo1 

lyge 

Class 

ADD NORMALIZED 

AER 

RR 

C 

ADD NORMALIZED 

AE 

RX 

C 

ADD NORMALIZED 

ADR 

RR 

c 

ADD NORMALIZED 

AD 

RX 

c 

ADD UNNORMALIZED 

AUR 

RR 

c 

ADD UNNORMALIZED 

AU 

RX 

c 

ADD UNNORMALIZED 

AWR 

RR 

c 

ADD UNNORMALIZED 

AW 

RX 

c 

COMPARE 

CER 

RR 

c 

COMPARE 

CE 

RX 

c 

COMPARE 

CDR 

RR 

C 

COMPARE 

CD 

RX 

c 

DIVIDE 

DER 

RR 

C 

DIVIDE 

DE 

RX 

c 

DIVIDE 

DDR 

RR 

c 

DIVIDE 

DD 

RX 

c 

HALVE 

HER 

RR 

c 

HALVE 

HDR 

RR 

c 

LOAD 

LER 

RR 

c 

LOAD 

LE 

RX 

c 

LOAD 

LDR 

RR 

c 

LOAD 

LD 

RX 

c 

LOAD AND TEST 

LTER 

RR 

c 

LOAD AND TEST 

LTDR 

RR 

c 

LOAD COMPLEMENT 

LCER 

RR 

c 

LOAD COMPLEMENT 

LCDR 

RR 

c 

LOAD NEGATIVE 

LNER 

RR 

c 

LOAD NEGATIVE 

LNDR 

RR 

c 

LOAD POSITIVE 

LPER 

RR 

c 

LOAD POSITIVE 

LPDR 

RR 

c 

LOAD ROUNDED 

LRER 

RR 

c 

LOAD ROUNDED 

LRDR 

RR 

c 

MULTIPLY 

MER 

RR 

c 

MULTIPLY 

ME 

RX 

c 

MULTIPLY 

MDR 

RR 

c 

MULTIPLY 

MD 

RX 

c 

STORE 

STE 

RX 

c 

STORE 

STD 

RX 

c 

SUBTRACT NORMALIZED 

SER 

RR 

c 

SUBTRACT NORMALIZED 

SE 

RX 

c 

SUBTRACT NORMALIZED 

SDR 

RR 

c 

SUBTRACT NORMALIZED 

SD 

RX 

c 

SUBTRACT UNNORMALOZED 

SUR 

RR 

c 

SUBTRACT UNNORMALIZED 

SU 

RX 

c 

SUBTRACT UNNORMALIZED 

SDR 

RR 

c 

SUBTRACT UNNORMALIZED 

SD 

RX 

c 


Figure 8.6 

Floating-Point Instructions 


Versi on 1.0 
15 June 1976 


Description 

P0P37 0 ■166 
P0P370:166 
POP370:166 
POP370 = 166 
POP37 0 = 167 
POP370:167 
POP370:167 
POP370:167 
POP370:167 
POP370 •• 167 
POP370 : 167 
P0P370 = 167 
POP370 : 168 
POP370 : 168 
POP370:168 
POP370 : 168 
P0P37 0*169 
POP370 :169 
POP370:170 
POP370 : 170 
POP370 •• 170 
POP370:170 
POP370 : 170 
POP370 : 170 
P0P37 0 = 170 
P0P370:170 
POP370 ; 171 
P0P37 0 : 171 
POP370*171 
P0P37 0 •' 171 
POP370 : 171 
POP370:171 
POP370*172 
POP370:172 
P0P370* 172 
POP370:172 
POP370:173 
P0P37 0 = 173 
POP370--173 
POP370:173 
POP370 = 173 
POP370:173 
POP370■174 
POP370 •• 174 
POP370 = 174 
POP370 = 174 
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Name 

Symbol 

Type 

Class 

Description 

ADD NORMALIZED 

AXR 

RR 

C 

P0P370 : 166 

MULTIPLY 

MXDR 

RR 

C 

POP370:172 

MULTIPLY 

MXD 

RX 

C 

POP370 = 172 

MULTIPLY 

MXR 

RR 

c 

POP370:172 

SUBTRACT NORMALIZED 

SXR 

RR 

c 

P0P37 0 : 17 4 


Figure 8.7 

Extended Floating-Point Instructions 
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9.0 SERVICE PROCESSES 

Service processes arise from process 
models built-in to the system and 
connected to process sources trig¬ 
gered by certain specified system 
events. They provide a means to re¬ 
spond to these events with a range of 
procedures, from simple to complex, 
not practical to obtain by adjusting 
parameters of closed functions. 

9.1 Tha System clock 

A real-time clock is included as an 
integral part of every EPSILON sys¬ 
tem. The clock is a 64-bit binary 
counter whose value is an unsigned 
fixed-point binary number, with bi¬ 
nary point located between bits 51 
and 52. The zero value represents 1 
January 1975, 0 hrs Greenwich Mean 
Time, which is the epoch standard for 
all EPSILON systems. Other values of 
the clock represent microseconds and 
fractions of a microsecond of time 
elapsed since the epoch. The actual 
resolution of the clock may be higher 
or lower than one microsecond, de¬ 
pending on the model of EPSILON sys¬ 
tem, but in all models bit positions 
are incremented at such a frequency 
that the rate of advancement is the 
same as if a 1 were added to bit po¬ 
sition 51 every microsecond. The in¬ 
crementing behavior and format of the 
clock are therefore the same as a 
System/370 time-of-day clock 
[POP370 ■ 42]. 

The clock is set during system in¬ 
itialization to a value which is com¬ 
puted by subtracting the epoch from 
the calendar date and time of in¬ 
itialization. Once set, it runs con¬ 
tinually until the system is powered 
down or re-i nit i alized . Other system 
activities and events do not affect 
it, and there are no instructions by 
which a process can alter its value. 
Consequently, clock values are con¬ 
sistent for all processes in a sys¬ 


tem, and provide a consistent means 
of recording transaction times or 
specifying when activities are to be 
initiated. For this purpose, any 
process can execute a STORE CLOCK in¬ 
struction (STCK), which stores the 
current value of the system clock in¬ 
to a double-word located by tha in¬ 
struction operand. 

Because of epoch standardization, 
clock values are also basically con¬ 
sistent between EPSILON systems and 
between initializations of any par¬ 
ticular system. However, unless the 
clock is tied to an external 
time-synchronizing signal (e.g. WWV) 
by tha clock synchronization fea¬ 
ture, inaccuracies of a second or 
more in setting its value to true ex¬ 
ternal time are likely to occur be¬ 
cause of operator reaction-time 
delays. These could introduce some 
inconsistencies between systems. In 
any event, a clock is always consist¬ 
ent within a single system, and as 
long as it is running always records 
elapsed time accurately to within the 
incrementing resolution. 

9.2 Tirng Events 

The system clock is a source for a 
family of service processes called 
time event processes. The process 
model connected to it for this pui— 
pose is an R-process model whose RMDB 
has fields filled with fixed data 
supplied by the system, and empty 
fields which must be filled before a 
process of the family can be initi¬ 
ated. The fixed data fields are 
those which specify conditions of us¬ 
age or circumscribe the behavior of 
processes of the family. 

o The bits of field RMFLG [Figure 
6.1] are set so that 

process statistics are col- 
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lected 

the domain identifier of 
processes of the family is 
derived from the process 
which caused initiation 

the process model is 
single-instance 

the entry context space i s 
bound to the custody of the 
model 

the process model is in pub- 
1ic custody. 

o A null exception module is speci¬ 
fied by field RMXMD. 

o The entry context space is speci¬ 
fied at system initialization. 

The process model is assigned to pub¬ 
lic custody in order to allow the re¬ 
maining fields of the RMDB to be 
specified by instruction execution. 
The assignment has no other conse¬ 
quences, as the clock does not have 
an explicit source identifier, and so 
cannot be referenced by instructions 
which apply to ordinary sources. In 
particular, the process model cannot 
be modified by CRPM or CRPMI, nor can 
initiation of a process of the family 
be requested by SGS. For time event 
processes, both these functions are 
combined into the REQUEST TIME EVENT 
instruction (RTE). 

The RTE instruction, which can be ex¬ 
ecuted within any C-process or R-pro- 
cess, is unlike other instructions in 
that the action requested by the in¬ 
struction is not carried out until 
the system clock reaches a specified 
value. The clock value is supplied 
in a Time Event Request Block (TERB), 
which also contains process model da¬ 
ta. A TERB must begin on a word 
boundary and have the format de¬ 
scribed in figure 9.1. 


An RTE instruction will be rejected 
if the TERB is not located within an 
ordinary M-space which is in process 
or family custody of the process 
within which the instruction is being 
executed. It will also be rejected 
if the TIME field of the TERB con¬ 
tains a clock value already attained, 
if the TEMOD field does not identify 
a module M-space to which the re¬ 
questing process has read access, or 
if the TELOC field does not designate 
an instruction address within the 
space. If the request is accepted, 
the space containing the TERB is re¬ 
moved from custody of the process ex¬ 
ecuting the RTE and place into an 
internal queue called the timing 
quaua. Null pointers are loaded into 
all pointer registers of the process 
which contain a pointer to the space, 
and the reference count of the space 
is decremented by 1 for each null 
pointer loaded. The RTE itself is 
then complete. 

Spaces in the timing queue are oi— 
dered by the clock value of their 
TERB, with the smallest value at the 
head of the queue. When the clock 
attains the value of the item at the 
head of the queue, the request asso¬ 
ciated with the item becomes effec¬ 
tive. 

o The space i s removed from the 
timing queue and its reference 
count is examined. If the count 
is not zero, the request is nul¬ 
lified by deleting the space from 
the system. 

o If the count is zero, the empty 
fields of the RMDB, which corre¬ 
spond to the instruction counter 
fields RMMOD, RMMSK, and RMLOC, 
are filled from fields TEMOD, 
TEMSK, and TELOC respectively. 

o When the RMDB is completed, the 
equivalent of an SGS instruction 
[Section 6.3] is executed. The 
communication space for the SGS 
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TIME 


TEMOD 


TEMSK 


TELOC 


/•" 



Fi gure 9.1 

Time Event Request Block 


Field Offset Bytes 


Description and Use 


TIME 

0 

8 

Clock value e 

initiated. 

TEMOD 

8 

4 

A pointer to 
tial instruci 

cess. 

TEMSK 

12 

1 

Value of the 

process. 

TELOC 

13 

3 

Base address 
TEMOD of the 
struction seq 


t which the time event process is to be 

the module M-space containing the ini- 
ion sequence to be executed by the pro¬ 
exception mask for initial entry to the 

within the M-space identified by field 
first instruction of the initial in- 


is the space which 

was in 

the 

and 

the processes 

should use as In¬ 

timing queue. 

and 

the 

tie 

time for their 

activity as possi- 

communication data 

supplied 

to 

ble. 



the process is the 

location 

of 





the TERB in the space. 9.3 System Exceptions 


Action of the timing queue is inhib¬ 
ited while there is a time event pro¬ 
cess in existence. This assures the 
independence of individual time 
event requests, but as a consequence 
some requests may not become effec¬ 
tive precisely at the specified clock 
time. Moreover, the actual time of 
initiation of a time event process 
after the request is effective de¬ 
pends on the dispatching priority as¬ 
signed to the clock at system 
initialization. Therefore, if time 
event processes are to be used to 
trigger key events for a system or 
application, the clock should be as¬ 
signed a high dispatching priority. 


A system exception is raised during 
execution of a closed function when 
an unusual condition is encountered 
which may be significant to applica¬ 
tions, but does not indicate system 
damage or malfunction. A special 
class of system exceptions can also 
be raised by execution of a FORCE 
SYSTEM EXCEPTION instruction within 
any process. 

An exception or a class of exceptions 
acts as a source for a family of 
service processes. The associated 
process models are defined and con¬ 
nected at system initialization, and 
as they have no referents cannot be 


r 
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modified or deleted by ordinary con¬ 
nection instructions, nor can initi¬ 
ation requests be triggered by ordi¬ 
nary request instructions. Because 
an exception process is intended to 
provide a means by which action can 
be taken to note, modify, or remove 
the .exception condition, the pro¬ 
cesses are supplied with entry data 
which defines the source and context 
of the exception. In addition, each 
process model is granted some special 
rights of custody and access in order 
to allow processes of its family to 
take effective action related to the 
exception. 

There are process models correspond¬ 
ing to the exception sources 1 

system overrun 
invalid process model 
forced exception 
statistics collection 
domain end. 

The entry data and process model con¬ 
ventions which apply to each excep¬ 
tion source are described in the 
remainder of this chapter. 

9.4 System Overrun 

A system overrun exception is raised 
when a computation cycle overrun con¬ 
dition is established [Section 4.71. 
The process model connected to the 
exception is a C-process model whose 
CMDB contains the following data. 

o The bits of field CMFLG [Figure 
5.1] are set so that 

process statistics are col¬ 
lected 

the domain identifier is 
fixed as the identifier of 
the entry context space 

the entry context space is 
bound to the custody of the 
modal 


the process model is in sys¬ 
tem custody. 

o The module space identified by 
field CMMOD is specified at sys¬ 
tem initialization, as part of 
the specification of the compu¬ 
tation cycle structure. If the 
space is the null space, system 

overruns will be ignored. If the 
space is non-null, it is bound to 
the custody of the process model . 
Fields CMMSK and CMLOC are set to 
zero. 

o The process modal is 

single-instance. The process 
model name is an internal system 
name, and is model dependent. 

o A null exception module is speci¬ 
fied by field CMXMD. 

o The entry context space is speci¬ 

fied at system initialization. 

o There is an associated input 

queue whose name is the same as 
the process model name. 

When an overrun exception occurs, an 
M-space is placed into the overrun 
input queue which describes the con¬ 
tent of the computation cycle list at 
the time of overrun. If there had 
not been a previous overrun, the 
queue will be empty; if it is not 
empty, either an overrun process ex¬ 
ists or the queue was not emptied by 
a previous overrun process. In the 
latter case, the existing items are 
deleted from the queue before the new 
item is entered. 

The overrun process model is assigned 
to a special computation cycle which 
is higher in precedence than all oth¬ 
er computation cycles. Inasmuch as 
an overrun condition is recognized by 
dispatching at the expiration of a 
basic cycle, the initiation request 
will be honored at once, and initi- 
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ation will start before any other 
C-process is assigned a CPU. If 
field CMMOD of the CMDB identifies an 
M-space or a B-space with an existing 
M-space descendent, the overrun pro¬ 
cess itself will be dispatched before 
other processes; otherwise, the 
overrun process will be delayed until 
an M-space containing its initial in¬ 
struction sequence is available 
[Sect ion 5.4], 

An overrun process is a reqular pro¬ 
cess which can execute all instruc¬ 
tions available to C-processes. In 
particular, using the STORE CMDB in¬ 
struction to obtain the names of in¬ 
put queues, it can send messages to 
any of the C-processes in the compu¬ 
tation cycle list. Conventions can 
therefore be established by which 
C-processes will accept messages 
from an overrun process to modify or 
terminate their activity. If more 
direct action is desired, the overrun 
process can itself force termination 
of other processes. The overrun pro¬ 
cess model i s treated as a system 
custodian with respect to C-process 
models, so an overrun process can ef¬ 
fectively terminate any C-process by 
use of the TERM instruction. 

Each item placed into the overrun 
queue consists of a header and a set 
of computation cycle records, one for 
each computation cycle. The format 
of the header is described in figure 
9.2; the format of an individual com¬ 
putation cycle record is described in 
figure 10.3 [Section 10.2]. 

9.5 Invalid Process Modal 

An invalid process model exception 
can be raised either while attempting 
to initiate a process or to handle a 
process exception. The exception is 
raised during process exception han¬ 
dling, for a process of any process 
class, if the current exception mod¬ 
ule [Section 5.13] has been deleted 
from the system, or if the process 


does not have read access to the 
space. The exception is raised dui— 
ing initiation 

o for a C-process model if initial 
or exception module data is not 
valid: field CMMOD must identify 
either the null space or a module 
space for which field CMLOC des¬ 
ignates instruction location 
within the space., field CMXMD 
must identify either the null 
space or a module space, and 
field CMCTX must identify either 
the null space or an ordinary 
space 

o for an R-process model if the 

M-space identified by field 
RMMOD has been deleted from the 
system 

o for a D-process model if the 

M-space identified by field 
DMMOD has been deleted 

o for a model of any class if pro¬ 
cesses of the family do not have 
read access to the space contain¬ 
ing the initial instruction se¬ 
quence . 

The process model connected to the 
exception is an R-process model whose 
RMDB contains the following data. 

o The bits of field RMFLG are set 
so that 

process statistics are col¬ 
lected 

the domain identifier for 
processes of the fami ly i s 
derived from the process 
which caused initiation 

the process model i s 
multi-instance 

the entry context space i s 
bound to the custody of the 
model 
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CCNO 

OVCYC 

OVID 

OVSEQ 


Figure 9.2 
Overrun Header Word 


Field 

Offset 

Bvtes 

Description and Use 


CCNO 

0 

1 

Number of computation cycles in the system 

. 

OVCYC 

1 

1 

Overrun cycle indicator [Section 4.71. 


OVID 

2 

1 

Identifier of the computation cycle for 
overrun was established. 

whi ch 

OVSEQ 

3 

1 

Sequence number of the overrun computation 

cycle. 


the process model is in sys¬ 
tem custody. 

o The module M-space identified by 
field RMMOD is specified at sys¬ 
tem initialization, and bound to 
to the custody of the model. 
Fields RMLOC and RMMSK are set to 
zero. 

o A null exception module is speci¬ 
fied by field RMXMD. 

o The entry context space is speci¬ 
fied at system initialization. 

When an invalid process model excep¬ 
tion occurs, an M-space large enough 
to contain the process model defi¬ 
nition block is allocated, the defi¬ 
nition data is copied into it, and 
the equivalent of an SG5 instruction 
is executed. The location of the 
process model data becomes the commu¬ 
nication data for the exception pro¬ 
cess initiated as a result of the 
signal. The source of the exception 
is supplied in the initial state vec¬ 
tor, replacing standard information 
not applicable to an exception pro¬ 
cess. 


o The condition code describes the 
class of process which caused the 
exception. It is zero for a 
C-process, 1 for an R-process, 
and 2 for a D-process. 

o Arithmetic register 1 contains 
the name of the process model, or 
the source identifier, or the 
device identifier, as appropri¬ 
ate for the process class. 

An invalid process model exception 
process is treated as a system custo¬ 
dian with respect to process models 
of all process classes. It can 
therefore modify the data in the 
entry context space and execute a 
DCPM, CRPM, or CDPM instruction to 
remove the defect in the process mod¬ 
el, or to delete the model from the 
system. If an exception process 
takes no action with respect to the 
offending process model, the effect 
on system behavior depends on the 
cause of the exception and the class 
of the model. 

o If the exception resulted from 
deletion of an exception module, 
the process which triggered the 
exception remains in existence 
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and is treated as if it had no 
exception module current. The 
system exception continues to be 
raised whenever a process excep¬ 
tion occurs for a member of the 
same family. Hence, in this case 
the effect is simply an increase 
in the total system activity gen¬ 
erated by process exceptions. 

o If the exception is raised during 
initiation, the initiation at¬ 
tempt is abondoned and the initi¬ 
ation request is deleted from the 
system without initiating a pro¬ 
cess. If the request was trig¬ 
gered by entry of a space into an 
input queue of a C-process model, 
the space remains in the queue, 
but does not inhibit further ini¬ 
tiation requests by the queue. 
In such a case, the effect may be 
indefinite accumulation of 
spaces into the queue or queues 
associated with the invalid pro¬ 
cess model. 

To forestall diversion of storage re¬ 
source into spaces which cannot be 
used, the system will force deletion 
of any process model for which a 
total of 256 invalid process model 
exceptions are raised while attempt¬ 
ing initiation. 

9.6 Forced Exception 

A system exception is forced by exe¬ 
cution of a FORCE SYSTEM EXCEPTION 
instruction (FSX) within a process of 
any process class. The process model 
connected to the exception is an 
R-process model whose RMDB contains 
the following data. 

o The bits of field RMFLG are set 
so that 

process statistics are col¬ 
lected 

the domain identifier is de¬ 
rived from the process which 


caused initiation 

the process model i s 
multi-instance 

the entry context space is 
bound to the custody of the 
model 

the process model is in sys¬ 
tem custody. 

o The module M-space identified by 
field RMMOD is specified at sys¬ 
tem initialization, and bound to 
the custody of the model. Fields 
RMLOC and RMMSK are set to zero. 

o A null exception module is speci¬ 
fied by field RMXMD. 

o The entry context space is speci¬ 
fied at system initialization. 

FSX is similar to SGS in that it 
transmits communication data to the 
process initiated in response to the 
signal. However, as the reason for 
forcing an exception may well be a 
condition which inhibits continua¬ 
tion of a process and which the pro¬ 
cess itself cannot rectify or bypass 
(e.g. space for critical data cannot 
be allocated), FSX has a normal be¬ 
havior which differs somewhat from 
that of SGS. 

o The communication context is ex¬ 
pected to be a number, not a lo¬ 
cation in some M-space. Unless 
the 'space location' option is 
selected, the context is gener— 
ated by combining the null point¬ 
er with the arithmetic register 
designated by the instruction 
operand. 

o If the 'continue activity' 
option is not selected, a return 
is made to dispatching to suspend 
the process within which the in¬ 
struction is being executed and 
switch the CPU to another. The 
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suspended process will be re¬ 
turned to ready dispatching con¬ 
dition upon termination of the 
exception process initiated in 
response to the signal. 

The dispatching priority of the 
forced exception process model is as¬ 
signed at system intitialization. If 
an R-process whose dispatching pri¬ 
ority is higher than the assigned 
priority is suspended as a result of 
executing FSX, the corresponding ex¬ 
ception process is promoted to a pri¬ 
ority higher than the suspended 
process. A forced exception process 
is therfore always of higher dis¬ 
patching priority than any process 
suspended in its favor. 

9.7 Statistics Collection 

A statistics collection exception is 
raised on overflow of a statistics 
collection counter, or when a queue 
or process model with active statis¬ 
tics collection is deleted from the 
system [Section 10.31. The process 
model connected to the exception is a 
C-process model which is assigned to 
a computation cyle selected at system 
initialisation. The CMDB for the 
model contains the following data. 

o The bits of field CMFLG are set 
so that 

process statistics are col¬ 
lected 

the domain identifier for 
processes of the family is 
fixed as the ientifier of the 
entry context space 

the entry context space is 
bound to the custody of the 
model 

the process model is in sys¬ 
tem custody. 

o The module space identified by 


field CMMOD is specified at sys¬ 
tem initialisation. If the space 
is null, the statistical data 
collected will be discarded. If 
the space is not null, it is 
bound to the custody of the mod¬ 
el. Fields CMMSK and CMLOC are 
set to zero. 

o The process model i s 

single-instance. The process 
model name is an internal system 
name, and is model dependent. 

o A null exception module is speci¬ 
fied by field CMXMD. 

o The entry context space is speci¬ 

fied at system initialization. 

o There is an associated input 

queue whose name is the same as 
the process model name. 

When a statistics collection excep¬ 
tion occurs an M-space containing a 
record of accumulated data is placed 
into the input queue associated with 
the model. The format of the record 
in the space is described in Section 
10.5. Statistics collection excep¬ 
tion processes are regular processes 
which can use any of the instructions 
available to C-processes to dispose 
of the accumulated, data. 

9.8 Domain End 

A domain end exception is raised when 
a domain statistics counter ovei— 
flows, or when a domain end occurs 
because the membership count of a do¬ 
main goes to zero [Section 3.53. The 
process model connected to the excep¬ 
tion is a C-process modal which is 
assigned to a computation cyle se¬ 
lected at system initialization. The 
CflDB for the model contains the fol- 
lowing data. 

o The bits of field CMFLG are set 
so that 
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process statistics are col¬ 
lected 

the domain identifier for 
processes of the family is 
fixed as the ientifier of the 
entry context space 

the entry context space ? s 
bound to the custody of the 
model 

the process model is in sys¬ 
tem custody. 

o The module space identified by 

field CMMOD is specified at sys¬ 
tem initialization. If the space 
is null, domain end will be ig¬ 
nored. If the space is not null, 
it is bound to the custody of the 
model. Fields CMMSK and CMLOC 
are set to zero. 

o The process model is 


single-instance. The process 
model name is an internal system 
name, and is modal dependent. 

o A null exception module is speci¬ 
fied by field CMXMD. 

o The entry context space is speci¬ 
fied at system initialization. 

o There is an associated input 
queue whose name is the same as 
the process model name. 

When a domain exception occurs an 
M-space containing the resource us¬ 
age statistics accumulated for the 
domain is placed into the input 
queue. The record in the space is a 
special form of statistics record. 
Its format is described in Section 
10.6. Domain end exception processes 
are regular processes which can exe¬ 
cute all instructions available to 
C-processes. 


9.9 - Instruction Descriptions 


REQUEST TIME EVENT 


RTE Dl(Bl) <SI> 

The instruction is terminated with condition code 2 if the operand does 
not designate a location in an ordinary M-space which is in private or family 
custody of the process within which the instruction is being executed. It is 
suppressed with a specification exception if the location is not on a word 
boundary. 

The TERB located by the operand is examined for validity. If field TEMOD 
does not identify a module M-space to which the requesting process has read 
access, or if field TELOC does not designate an instruction address, the in¬ 
struction is terminated with condition code 3. It is terminated with condi¬ 
tion code 1 if the value contained in field TIME is smaller than the current 
value of the system clock. 

If the TERB is valid, the space identified by the operand is removed from 
custody of the process executing the instruction and inserted into the timing 
queue at a point corresponding to the clock value contained in field TIME. 
The reference count of the space is decremented by 1. A null pointer is loaded 
into pointer register B1 and into any other pointer register of the process 
which contains a pointer to the space, and the reference count is decremented 
by 1 for each pointer loaded. The instruction is then completed with condi- 
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tion code 2 ero. 

If the reference count of the space is not zero when the time event pro¬ 
cess corresponding to the TERB is initiated, the process is suppressed and the 
space is deleted from the system. 

Process Class: c,R 

Condition Code: 

0 Request accepted 

1 Time expired 

2 Invalid TERB space 

3 Invalid TERB data 

Exceptions : 

Specification 


STORE CLOCK 


STCK D2CB2) <RS> 

The current value of the sytem clock is stored in the double-word located 
by the second operand. Zeros are supplied in the low order bit positions be¬ 
low the resolution of the clock installed on the system. 

The instruction is suppressed with a specification exception if the opei— 
and does not define a location on a word boundary. 

Process Class 1 C,R,D 

Condition Code: Unchanged 

Except ions 1 

Specification 


FORCE SYSTEM EXCEPTION 


FSX Ml,R2 <RR> 

The conditions are raised which signal a forced system exception. 

The contents of general register R2 and bit zero of mask field Ml detei— 
mine the communication data to be provided to the process initiated as a re¬ 
sult of signalling the exception. If bit zero of mask field Ml is zero, the 
context consists of the null pointer combined with the contents of arithmetic 
register R2. The contents of the register are not disturbed. 

If the bit is 1, the context consists of the full general register. In 
that case, the instruction is terminated with condition code 3 if pointer reg- 
i ster R2 does not identify an ordinary M-space, if the space is in I/O request 
state, or if the space is not in private or family custody of the process with¬ 
in which the instruction is being executed. 

If the instruction is not terminated, a null pointer is loaded into point- 


Chapter 9 


137 


Service Processes 





Principles of Operation 
The EPSILON System 


Versi on 1.0 
15 June 1976 


er register R2 and into any other pointer register of the process which con¬ 
tains a pointer to the space. The reference count is decremented by 1 for each 
pointer loaded. The space is placed into system custody and retained as com¬ 
munication space for the exception process. If the reference count of the 
space is not zero at the time the exception process is initiated, that process 
will be suppressed and the space deleted from the system. 

Completion of the instruction is determined by bit 1 of mask field Ml. If 
the bit is zero, the process executing the instruction is suspended and con¬ 
trol of the CPU assigned to the process is returned to dispatching. The pro¬ 
cess will be returned to ready dispatching condition when the exception 
process terminates. The instruction will then be completed with condition 
code zero if the exception process terminates normally, and with condition 
code 1 if the process was suppressed. 

If bit 1 of mask field Ml is 1, the process executing the instruction con¬ 
tinues activity, and the instruction is completed with condition code 2. 

Process Class- - C,R,D 

Condition Code 1 

0 Exception process completed 

lException process suppressed 

2 Signal accepted 

3 Signal rejected 

Exceptions: Nona 
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10.0 SYSTEM INQUIRY FACILITIES 

System Inquiry facilities provide 
information describing the config¬ 
uration, current internal state, and 
operational history of an EPSILON 
system. The descriptions are genei— 
ated from internal tables and lists, 
or from statistics collected by the 
system control mechanisms. The basic 
mechanisms are used just to collect 
data about individual resources. 

Other mechanisms record interactions 
between resources and processes, and 
so have uses beyond basic data col- 
1ection. 

o Process monitoring mechanisms 

will record the resource usage of 
any process, trace its behavior, 
and raise a process exception if 
certain specified conditions 

arise. 

o Domain identification mechanisms 
will accumulate usage statistics 
by domain identifier. This data, 
together with the rules for 
acquisition of domain identifier 
by processes and spaces, pro¬ 
vides a means by which group 
identification can be used to de¬ 
fine, control, and account for 
units of work which are data-flow 
analogues of ’jobs' or 'ses¬ 
sions' . 

Some statistics are always collected 
when the collection facility is ac¬ 
tive, while the collection of others 
is controlled by instructions which 
specify what is to be collected and 
when. Statistics collection de¬ 
grades sytem performance to an extent 
which is model-dependent. However, 
no degradation will occur on any mod¬ 
el when the collection facilities are 
not active. 

10.1 Configuration Data 
An R-process or C-process can obtain 


information about the configuration 
of an EPSILON system using the STORE 
CONFIGURATION DATA instruction 
(SCON). Options selected for 
instruction execution determine 
whether 

o a Configuration Description 
Block (CDB) is stored 

o a computation cycle identifier 
list is stored 

o the information represents in¬ 
stalled conditions or current 
availabi1ity. 

The format of a CDB is described in 
figure 10.1. In this figure, if a 
field or bit description varies ac¬ 
cording to whether the block repres¬ 
ents installed conditions or current 
availability, the variable part of 
the description consists of two 
phrases enclosed in pointed brack¬ 
ets, separated by a vertical line. 
The first bracketed phrase applies to 
installed conditions, the second to 
current availability. If there are 
no brackets, the field description is 
invariant. 

If the computation cycle identifier 
option is selected, computation cy¬ 
cle identifiers are stored in succes¬ 
sive byte locations, beginning with 
the computation cycle of smallest pe¬ 
riod and proceeding in sequence 
[Section 4.1]. The entire set of 
identifiers is stored if the in¬ 
stalled condition option is selected 
along with the computation cyle 
option, while only the identifiers of 
cycles with an active process are 
stored if the current availability 
option is in effect. 

Although the SCON instruction 
options are independently select¬ 
able, the location of the stored data 
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SID 


FEAT 


Res 


STAT 


ERSM 


NPS 


NIOD 


CLK 


MSZ 


BSZ 


CCNO 


OCID 


CPU 


PPU 


BCT 


Figure 10.1 

Configuration Description Block 


Field Offset Bvtes 
SID 0 4 


FEAT 


4 

Bit 

0 


1 

Value 

0 

1 

0 

1 

0 

1 

0 

1 


Description and Use 

A 32-bit system identifier, assigned at the factory, 
which distinguishes the system from all other EPSILON 
systems. 

Bits defining the CDB content and system features 
Significance 

Installed conditions are described by this CDB 
Current availability is described by this CDB 

The floating-point instruction set is not <installed> 
I <currently available> 

The floating-point instruction set is <installed> | 
<currently available> 

The decimal instruction set is not <installed> | 
<currently available> 

The decimal instruction set is <installed> I <cui— 
rently available> 

The clock <is not synchronised to an external timing 
signal> | <value is valid> 

<The clock is synchronised to an external signal> | 
<clock damage reported but correction not yet ap- 
plied> 

Process monitoring not <installed> I <currently 
available> 
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1 

Process monitoring is <installed> | <currently avail- 
able> 

5 

0 

Software statistics not <installed> | <currently 
available> 


1 

Software statistics is <installed> | <currently 
available> 

6 

- 

Reserved 

7 

0 

Normal 


1 

Suspension of system operation has been requested. 

Field Offset 

Bvtes 

Description and Use 

STAT 6 

1 

<Initial> | <current> value of the statistics col¬ 
lection mask. The bits of this mask determine the 
conditions under which statistics are collected. 

Bit 

Value 

Siqnificance 

0 

0 

Statistical collection facility <is to be> | <is> in- 
act i ve 


1 

Statistical collection facility <is to be> | <is> ac- 
t i ve 

1 

0 

Do not collect I/O device statistics 


1 

I/O device statistics are to be collected 

2 

0 

Do not collect R-process source statistics 


1 

R-process source statistics are to be collected 

3 

0 

Do not collect queue statistics 


1 

Queue statistics are to be collected 

4 

0 

Do not collect process statistics 


1 

Process statistics are to be collected 

5 

0 

Do not collect domain statistics 


1 

Domain statistics are to be collected 

6 

0 

Do not collect software statistics 


1 

Software statistics are to be collected 

7 

0 

The value of this mask can be changed 


1 

The value of this mask cannot be changed 

Field Offset 

Bvtes 

Description and Use 

ERSM 7 

1 

<initial> | <current> value of the error signal mask. 
The bits of this mask, which determine the conditions 
under which error signals are effective, are de¬ 
scribed in Section 11.4. 
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NPS 

8 

2 

Number of process sources <installed on the system> 1 
<with process models connected>. 

NIOD 

10 

2 

Number of I/O devices <?nstalled on the system> | 
<with process models connected>. 

CLK 

12 

4 

High-order 32 bits of the clock value when <the sys¬ 
tem was last initialized> I <this CDB was stored>. 

MSZ 

16 

4 

Number of bytes of M-storage <installed on the sys- 
tem> I <not currently allocated>. 

BSZ 

20 

4 

Number of kilobytes of B-storage <installed on the 
system> | <not currently allocatad>. 

CCNO 

24 

1 

Number of computation cycles installed on the sys- 
tem> | <with an active process>. 

OCID 

25 

1 

<0verrun cycle indicator [Section 4.71> | <identifier 
of the computation cycle for which an overrun was 
last established>. 

CPU 

26 

1 

Number of CPU <installed on the system> | <currently 
available>. 

PPU 

27 

1 

Number of PPU <installed on the system> | <currently 
available>. 

BCT 

28 

4 

Basic cycle time in microseconds. 
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is affected by the combination se¬ 
lected. If both a CDB and a 
computation cycle list are stored* 
the list begins at the first location 
following the CDB. If only a list is 
stored, it begins at the location 
designated by the instruction opei— 
and. 

10.2 Current State Data 

C-processes and R-processes have ac¬ 
cess to process model data by means 
of the SCMDB, SRCE, and STDS instruc¬ 
tions. A C-process can obtain addi¬ 
tional current internal state data by 
use of 

o the STORE PROCESS MODEL LIST in¬ 
struction CSPML), which stores 
the names of all C-process models 


in the system 

o the STORE DOMAIN LIST instruc¬ 
tion (SDOL), which stores the 
names and identifiers of all do¬ 
mains in the system 

o the STORE QUEUE STATUS instruc¬ 
tion (SQS), which stores a block 
describing a specified queue, 
and 

o the STORE COMPUTATION CYCLE RE¬ 
CORD instruction (SCCR), which 
stores a block describing a spec¬ 
ified computation cycle. 

The SPML instruction stores the names 
of C-process models currently in the 
system, in successive word locations 
starting at a given location. The 


Chapter 10 


142 


System Inquiry Facilities 



Principles of Operation 
The EPSILON System 


Version 1.0 
15 June 1976 


number of words to be stored is spec¬ 
ified in the instruction, and a count 
of the number of names not stored is 
returned at instruction completion. 
The names are stored in arbitrary oi— 
der. The behavior of the SDOL 
instruction is the same as that of 
the SPML instruction, except that 
word pairs are stored, the first word 
containing the name of a domain and 
the second word containing its iden¬ 
tifier. 

The SQS instruction stores a Queue 
Status Record (QSR), in the format 
described in figure 10.2, for the 
queue whose q.ix is specified in the 
instruction. The C-process within 
which the instruction is executed 
need not be a member of the family 
having custody of the queue. 

The SCCR instruction stores a Compu¬ 
tation Cycle Status Record (CCSR), in 
the format described in figure 10.3, 
for the computation cycle whose iden¬ 
tifier is specified in the instruc¬ 
tion. The selection routine code 
contained in field SRT indicates the 
source of the routine as well as its 
specific type. Code values 0-127 are 
reserved for selection routines sup¬ 
plied with EPSILON systems or avail¬ 
able as factory installed options. 
The values for the standard routines 
[Section 4.4] are : 

0 = finite quential 

1 = infinite sequential 

2 = multiplexed. 

Code values of 128-255 are used for 
custom routines, and routines avail¬ 
able only for field installation. 

10,3 Collection of Statistics 

Statistics are collected in EPSILON 
systems by incrementing arithmetic 
counters when an event of statistical 
significance occurs. A set of stand¬ 
ard statistical counters is formed by 
microcode during operation of all 


systems. The set varies in size and 
content as demands for statistics 
fluctuate. Some of these counters 
are incremented automatically by 
microcode; the others are incre¬ 
mented by execution of the COLLECT 
STATISTICS instruction (CSTAT) . A 
software statistics feature, which 
can be installed on any modal, pro¬ 
vides the ability to define counters 
by instruction execution, and to dis¬ 
play the value of counters at any 
time. 

A counter is 8, 16, 32, or 64 bits in 
length, depending on the kind of data 
it accumulates. Counters are organ¬ 
ized into groups which accumulate da¬ 
ta associated with some entity 
recognized by the system. The type 
of entity with which a group of 
standard counters can be associated 
i s 

the system, 
an I/O device, 
an R-process source, 
a queue, 

a process family, or 
a domain. 

A software counter group accumulates 
data collected by some set of pro¬ 
cesses; the data may or may not be 
related by other associations. 

Counter groups consist of a set of 
non-addressable counters, which are 
incremented by microcode, and a set 
of addressable counters, which are 
incremented by the CSTAT instruc¬ 
tion. There can be a maximum of fif¬ 
teen addressable counters in any 
group, with no more than eight 8-bit 
counters, four 16-bit counters, two 
32-bit counters, and one 64-bit coun¬ 
ter. The composition of a group is 
determined by the type of entity with 
which the group is associated. The 
system activity group contains only 
non-addressable counters, a software 
group contains only adressable coun¬ 
ters, while the groups associated 
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Field 

QFLG 


Field 

QSEQ 

QICT 

QIX 

QNME 

QPM 



Figure 10.2 
Queue Status Record 


Offset Bytes 

0 1 

Bit Value 

0 0 

1 


Description and Use 

Bits defining the type and status of the queue. 

Significance 

This is an input queue 
This is a public queue 


1 


0 

1 


Normal 

This queue has been primed to trigger initiation (in¬ 
put queue only) 


2 


0 

1 


Normal 

A process is in queue wait for this queue 


3 


0 

1 


Normal 

The value in field QICT is not a true value 


4-7 - Reserved 


Offset Bvtes 


Description and Use 


1 


2 


4 


1 Contains the precedence sequence number of an input 
queue, and zero for a public queue. High precedence 
corresponds to low number. 

2 Count of the number of items in the queue, modulo 
16,384. Bit 3 of field QFLG is set to 1 if the true 
count exceeds 16,383. 

4 Q.ix of the queue for which this record was stored. 


8 4 


Name of the queue for which this record was stored. 


12 4 Contains the name of the associated C-process model 

for an input queue, and the name of the custodian pro¬ 
cess model for a public queue. 
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CCID 

CCPER 

SRT 

OSC 

PMCT 

PMLST 


Figure 10.3 

Computation Cycle Status Record 


Field 

Offset 

Bvtes 

Description and Use 


CCID 

0 

1 

Identifier of the computation cycle corresponding 
the record. 

to 

CCPER 

1 

3 

Period of the cycle [Section 4.11. 


SRT 

4 

1 

Type of selection rountine in use by the cycle. 


OSC 

5 

1 

Overrun sequence count for the cycle [Section 4.7] 

• 

PMCT 

6 

2 

Number of process models with a process active in 
cycle. 

the 

PMLST 

8 

Var 

Names of the process models, listed in arbitrary 
der; the number of entries in the list is equal to 
value of field PMCT. 

oi— 

the 


with other types contain both kinds 
of counters. 

The counter affected by a CSTAT in¬ 
struction is addressed by first se¬ 
lecting a group, and then designating 
a particular counter within that 
group. Group selection is accom¬ 
plished by applying modal con¬ 
ventions to reference a particular 
group within a designated type of 
group. 

o Group type is designated by a 
number between 0 and 7 : 

0 = system 

1 = I/O device 

2 = R-process source 

3 = queue 

4 = process 


5 = process family 

6 = domain 

7 = software. 

o At any given time, a process can 
address at most one group of any 
designated type. Types 4, 5, 6, 
and 7 are treated uniformly for 
all processes. For type 4, the 
group selected is the group asso¬ 
ciated with the process itself. 
For type 5, it is the group asso¬ 
ciated with the family of the 
process. For type 6, it is the 
group associated with the domain 
on whose behalf the process i s 
currently acting. For type 7, it 
is the software group current for 
the process [Section 10.51. 

o Types 1, 2, and 3, which are as- 
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sociated with process sources, 
are treated modally. A D-process 
which designates type 1 refers to 
the group associated with its own 
I/O device. An R-process which 
designates type 2 refers to the 
group associated with its own 
source. A C-process which desig¬ 
nates type 3 refers to the group 
associated with its current 
queue. Any other designation of 
these types will select a null 
group of counters. 

o Designation of type zero by a 
process of any class results in 
selection of a null counter 
group. 


A null group is also selected if the 
group which normally would be se¬ 
lected does not exist because counter 
assignment has been suppressed 
[Sect ion 10.41. 

The address of a particular counter 
within the selected group is always 
designated by a fixed number, irre¬ 
spective of whether the counter is 
actually contained in the group: 

1-8 are 8-bit counters 
9-12 are 16-bit counters 
13-14 are 32-bit counters 
15 is the 64-bit counter 

while 0 is used to designate the en¬ 
tire set of addressable counters of a 
group. If the selected group is a 
null group, or if the designated 
counter is not contained in the 
group, the address is taken to refer 
to a null counter. 

To apply these addressing con¬ 
ventions, the RS format is used for 
the CSTAT instruction. The R3 field 
specifies the type of group, and the 
R1 field the particular counter. The 
R3 field also defines the action to 
be performed on the counter. 

o If the R3 field contains a true 


type number, the counter is to be 
incremented. If the field value 
is a type number plus 8, the 
counter is to be set to a given 
value. For example, a 3 in the 
R3 field specifies that a queue 
counter is to be incremented, 
while an 11 in the field speci¬ 
fies that a queue counter is to 
be loaded with a value. 

o The second operand locates the 
value by which the counter is to 
incremented or set. The operand 
length is taken to be equal to 
the length of the counter. 

o If a null counter is selected, 
the instruction is terminated 
without taking any action except 
to set a condition code. The 
condition is not considered to be 
an error, and no exception is 
raised. 

The setting of the statistics col¬ 
lection mask, which is displayed in 
field STAT when a CDB is stored [Fig¬ 
ure 10.1], determines whether or not 
a counter is actually modified when 
addressed by a CSTAT instruction or 
by microcode. 

o Bit zero of the mask is the mas¬ 
ter switch. If the bit is zero, 
the statistical collection mech¬ 
anisms are inactive. No counters 
will be modified, either auto¬ 
matically or by instruction exe¬ 
cution, and no performance 
degradation will occur. If the 
bit is 1, the collection mech¬ 
anisms are active, as specified 
by the remaining bits of the 
mask. 

o Bits 1 through 4 are switches for 
I/O device, R-process source, 
queue, and process family 
groups, respectively. Bit 5 con¬ 
trols collection of domain sta¬ 
tistics, and bit 6 controls the 
software counters, if the soft- 
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ware feature is installed. If a 
bit is zero, the counters of the 
type of group it controls are not 
active. If a bit is 1, counter 
groups of that type are active, 
and will be modified if ad¬ 
dressed. The system activity 
counters are not controlled by 
the mask, as they are always ac¬ 
tive. 

o Bit 7 determines whether or not 
the value of the mask can be 
changed. If the bit is zero, the 
mask can be set to another value; 
if the bit is 1, the mask value 
cannot be changed. 

The initial value of the statistics 
collection mask is specified at sys¬ 
tem initialization. If bit 7 is then 
zero, the mask can be set to any oth¬ 
er value by execution of the SET COL¬ 
LECTION MASK instruction (SCM) 
within any C-process or R-process. 
SCM exchanges mask bytes in the man¬ 
ner of SXM and SBKM, and will contin¬ 
ue to do so as long as bit 7 of the 
new mask remains zero. 

10.4 Assignment of Counters 

Storage for statistical counters is 
withdrawn from the M-storage pool 
when a counter group i s to be formed; 
the storage is returned to the pool 
when the group is no longer needed. 
An area of M-storage may be reserved 
at system initialization exclusively 
for use by counters. If storage is 
not available in the reserved area 
when a counter group i s to be formed, 
an attempt will be made to obtain 
storage from the general M-storage 
pool. If the attempt is successful, 
the storage is allocated to the 
group, but is not made a part of the 
reserved area; it will be returned to 
the general pool when the counter 
group is deleted. 

If storage is not available when a 
counter group is to be formed, as¬ 


signment of the group is suppressed, 
and a null group is substituted in 
its place. Suppression of counter 
assignment is a means of limiting the 
amount of M-storage absorbed by sta¬ 
tistics collection. It is not con¬ 
sidered to be an error condition. No 
exception of any kind is raised, nor 
is the functional behavior of pro¬ 
cesses affected. 

Counter assignment is also sup¬ 
pressed whenever operating condi¬ 
tions indicate that statistics for an 
entity can never be collected. For 
example, if bit 7 of the statistics 
collection mask is 1 and bit 3 is ze¬ 
ro, queue statistics cannot be col¬ 
lected unless the system is 
re-initialized. Consequently, coun¬ 
ter assignment is suppressed for 
queues defined after the mask was 
set. The rules for counter assign¬ 
ment all follow this principle. 

o The system counter group is a 
unique group which is assigned at 
system initialization. Assign¬ 
ment is suppressed if at that 
time bit 7 of the statistics col¬ 
lection mask is 1 and bit zero is 
zero. 

o An I/O device is assigned coun¬ 
ters at system initialization. 
Counter assignment is suppressed 
if bit 7 of the statistics col¬ 
lection mask is 1 and either bit 
zero or bit 1 is zero. 

o An R-process source is assigned 
counters at system initializa¬ 
tion. Counter assignment is sup¬ 
pressed if bit 7 of the 
statistics collection mask is 1 
and either bit zero or bit 2 is 
zero. 

o A queue is assigned counters when 
it is defined. Counter assign¬ 
ment is suppressed if bit 7 of 
the statistics collection mask 
is 1 and either bit zero or bit 3 
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is zero. If the queue is an in¬ 
put queue, counter assignment is 
also suppressed if the C-process 
model with which it is associated 
has a CMDB for which bit zero of 
field CMFLG is zero. 

o A process is assigned counters 
when it is initiated, a process 
model when it is defined or con¬ 
nected. Counter assignment is 
suppressed in either case if bit 
7 of the statistics collection 
mask is 1 and either bit zero or 
bit 4 is zero. Counter assign¬ 
ment is also suppressed if bit 
zero of the XMFLG field of the 
XMDB for the model is zero (X be¬ 
ing C, R, or D). 

Domain counter assignment [Section 
10.63 is suppressed by bit 5 of the 
statistics collection mask, and 
software counter assignment [Section 

10.7] by bit 6 . 

10.5 Statistics Records 

The data collected in the statistical 
counters is made available when a 
statistics collection end event 
occurs. Each such event raises a 
statistics collection system excep¬ 
tion, which causes a statistics col¬ 
lection record (SCR) to be placed 
into the statistics queue [Section 

9.7] and modifies counter values or 
usage. 

o If incrementation would cause a 
counter of any group to overflow, 
an overflow SCR is enqueued be¬ 
fore the counter is modified. 
The entire counter group is then 
reset to zero and normal incre¬ 
menting proceeds from that 
point. 

o If a queue is deleted from the 
system by QDEL or during replace¬ 
ment of a C-process model, a 
queue deletion SCR is enqueued. 
The counters assigned to the 


queue are then deleted from the 
set of standard counters. 

o When a process of a family for 
which statistics are to be col¬ 
lected terminates, a process end 
SCR is enqueued. The counters 
assigned to the process are com¬ 
bined into the appropriate coun¬ 
ters assigned to the family, and 
the process counters are then de¬ 
leted from the set of standard 
counters. 

o When a process model for which 
family statistics are to be col¬ 
lected is deleted from the system 
permanently, rather than as an 
intermediate step during 

replacement, a process model de¬ 
letion SCR is enqueued. The 
counters assigned to the model 
when it was defined or connected 
are then deleted from the set of 
standard counters. When a C-pro¬ 
cess model with input queues is 
deleted, the SCR for the queues 
are placed into the queue follow¬ 
ing the SCR for the modal. 

I/O device, R-process source, and 
system SCR can be enqueued only on 
counter overflow unless the software 
statistics feature is installed on 
the system. Domain statistics are 
not available through the statistics 
queue. They are placed into the do¬ 
main queue [Section 9.8] when a do¬ 
main system exception is raised. 

The general form of an SCR is de¬ 
scribed in figure 10.4. The counters 
displayed in the SDTA field of a sys¬ 
tem SCR are all incremented by micro¬ 
code whenever an appropriate 
statistics event occurs, provided 
the master switch bit of the statis¬ 
tics collection mask is not zero. 
The format of this SDTA field is de¬ 
scribed in figure 10.5. 

An I/O device is assigned two non-ad- 
dressable counters, two 16-bit ad- 
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dressable counters, and eight 8-bit 
addressable counters at system in¬ 
itialization, if counter assignment 
is not suppressed at that time. 
These counters are displayed in the 
SDTA field of an I/O device SCR, in 
the format described in figure 10.6. 
In that figure, the addressable coun¬ 
ters have names of the form ACn, 
where n is an integer whose value is 
the same as the address value by 
which the counter is designated. 
This convention is employed whenever 
addressable counters are referenced. 

An R-process source is assigned two 
non-addressable counters, two 16-bit 
addressable counters, and four 8-bit 
addressable counters at system in¬ 
itialization, if counter assignment 
is not suppressed at that time. 
These counters are displayed in the 
SDTA field of an R-process SCR, in 
the format described in figure 10.7. 

A queue is assigned three non-ad¬ 
dressable counters, two 16-bit ad¬ 
dressable counters, and one 64-bit 
addressable counter when it is de¬ 
fined, if counter assignment is not 
suppressed at that time. These coun¬ 
ters are displayed in the SDTA field 
of a queue SCR, in the format de¬ 
scribed in figure 10.8. 

A process is assigned eight non-ad¬ 
dressable counters, one 32-bit ad¬ 
dressable counter, two 16-bit 
addressable counters, and three 
8-bit addressable counters, if coun¬ 
ter assignment is not suppressed when 
the process is initiated. These 
counters are displayed in the SDTA 
field of a process SCR, in the format 
described in figure 10.9. 

A process model is assigned six non- 
addressable counters, one 32-bit ad¬ 
dressable counter, two 16-bit 
addressable counters, and three 
8-bit addressable counters, if coun¬ 
ter assignment is not suppressed when 
the model is defined or connected. 


These counters are displayed in the 
SDTA field of a process family SCR, 
in the format described in figure 
10 . 10 . 

Counter assignments and format of a 
domain statistics record are dis¬ 
cussed in Section 10.6. Software 
statistics formats are described in 
Sect ion 10.7. 

10.6 Domain Statistics 

When a domain is formed, it is as¬ 
signed five non-addressable coun¬ 
ters, four 8-bit addressable 
counters, two 16-bit addressable 
counters, and one 32-bit addressable 
counter, provided counter assignment 
is not suppressed at that time. 
Counter assignment will be sup¬ 
pressed if bit 7 of the statistics 
collection mask is 1 and either bit 
zero or bit 5 is zero. The counters 
are displayed in the SDTA field of a 
domain SCR, in the format described 
in figure 10.11. 

A domain statistics record is placed 
into the domain system exception 
queue if a counter overflows, or if a 
domain is deleted because its membei— 
ship count has gone to zero. The 
purpose of treating domain statis¬ 
tics separately from other statis¬ 
tics is that domain end is noteworthy 
in itself; it may indicate, for exam¬ 
ple, a significant point in the data 
flow of an application. Consequent¬ 
ly, a domain end record (field SCDC 
equal 4) is always generated when the 
condition occurs, irrespective of 
whether statistics for the domain 
were collected. If there are no sta¬ 
tistics, the record ends with field 
CFRM, and field SLEN [Figure 10.4] 
will be set to reflect the shorter 
record length. 

10.7 Software Statistics 

The software statistics feature com¬ 
prises three instructions which pro- 
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Field 

STPE 

SCDC 


SLEN 

SCSQ 

STME 
SDT A 





Figure 10.4 

Statistics Collection Record 


Offset Bvtes Description and Use 

0 1 An integer between 0 and 7 which designates the type 

of counter group stored in field SDTA of the record. 
Values 8-255 are reserved. 


1 1 An integer which identifies the condition that caused 

the record to be generated: 

0 = counter overflow 

1 = process termination 

2 = queue deletion 

3 = process model deletion 

4 = domain end 

5 = instruction execution 

(software feature only) 

Values 6-255 are reserved. 


2 2 Length of the record in words. 

4 4 Sequence number of the record within the type desig¬ 

nated by field STPE. Sequence numbers are set to zero 
at system initialization, and are reset whenever the 
corresponding type bit in the statistics collection 
mask is set to zero. 


8 8 System clock time when the record was generated. 

16 Var Data accumulated in the counter group for which the 

record was generated. The format of this field 
varies with the type designated in field STPE. 
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SID 

MAID 

MALR 

MSPC 

BSPC 

NGTS 

MGND 

DIK 

CPRC 

CCO 

HOL 

RPR 

DPRC 

T CPU 

TPPU 


Figure 10.5 
System SCR Data 


Field 

Offset 

Bvtes 

Description and Use 

SID 

0 

4 

The system identifier assigned at the factory [Figure 
10.1] . 

MALD 

4 

2 

Number of system malfunctions detected during the pe¬ 
riod covered by this SCR. 

MALR 

6 

2 

Number of system malfunctions reported during the pe¬ 
riod. 

MSPC 

8 

2 

Number of M-spaces allocated during the period. 

BSPC 

10 

2 

Number of B-spaces allocated during the period. 

NGTS 

12 

2 

Number of access control gates closed during the pe~ 
r i od. 

MGND 

14 

1 

Maximum height of gate promotion during the period. 

DLK 

15 

1 

Number of R-process deadlocks detected during the pe¬ 
riod. 

CPRC 

16 

2 

Number of C-processes initiated during the period. 

CCO 

18 

1 

Number of computation cyle overruns established dui— 
ing the period. 

HOL 

19 

1 

Identifier of the highest level computation cycle for 


which an overrun was established during the period. 
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RPRC 

20 

2 

Number of R-processes initiated during 

the period. 


DPRC 

22 

2 

Number of D-processes initiated during 

the period. 


T CPU 

24 

4 

Total time in microseconds for which 
signed to some C-process or R-process 
r i od. 

a CPU was 
during the 

as- 

pe- 

TPPU 

28 

4 

Total time in microseconds for which a PPU was 
signed to some D-process during the period. 

as- 


DVID 

CLASS 

TYPE 

REQ1 

REQ2 

AC9 

AC1 0 

AC1 

AC2 

AC3 

AC4 

ACS 

AC6 

AC7 

AC8 


Figure 10.6 
I/O Device SCR Data 


Field Offset Bytes 


Description and Use 


DVID 0 2 

CLASS 2 1 

TYPE 3 1 

REQ1 4 2 


Identifier of the device for which this SCR was gen¬ 
erated . 

Class code of the device [Figure 7.1]. 

Type code of the device. 

Number of items placed into the request queue for the 
device during the period covered by this SCR. 


REQ2 6 2 


Number of items in the queue during the period which 
were put into I/O request state. 


AC9-10 8 2x2 


Contents of the 16-bit addressable counters assigned 
to the device. 


AC1-8 12 


8x1 Contents of the 8-bit addressable counters assigned 

to the device. 
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Field 

SRID 

TPR 

SPR 

AC9-10 

AC1-4 


SRID 

Reserved 

TPR 

SPR 

AC9 

AC10 

AC1 AC2 

AC3 AC4 


Figure 10.7 

R-process Source SCR Data 


Offset Bytes 
0 2 


Description and Use 

Identifier of the process source for which this SCR 
was generated. 


4 2 Number of R-processes initiated by the source during 

the period covered by this SCR. 

6 2 Number of R-processes initiated in the period as a 

result of an SGS instruction. 

8 2x2 Contents of the 16-bit addressable counters assigned 

to the source. 

12 4x1 Contents of the 8-bit addressable counters assigned 

to the source. 


QNME 

QIX 

ICT 

IMX 

TWTE 

AC9 

AC10 

AC 

us 

_ 


Figure 10.8 
Queue SCR Data 
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Field 

QNME 

QIX 

ICT 

IMX 

TWTE . 

AC9-10 

AC15 


Field 

PCI 


Offset Bytes 
0 4 


4 

8 

10 


Description and Use 

Name of the queue for which this SCR was generated. 
Index of the queue. 

Number of items placed into the queue during the pe¬ 
riod covered by this SCR. 

Maximum number of items in the queue during the peri¬ 
od . 


12 8 Maximum waiting time of an item in the queue during 

the period. The format of the field is that of the 
system clock. 

20 2x2 Contents of the 16-bit addressable counters assigned 

to the queue. 

24 8 Contents of the 64-bit addressable counter assigned 

to the queue. 



PCL AC1 

AC2 AC3 

PMID 

MSPC 

BSPC 

NGTS 

NIOR 

NX1 

NX3 

TPU 

AC9 

AGIO 

AC13 


Figure 10.9 
Process SCR Data 


Offset Bytes 


Description and Use 


0 1 Process class of the process for which this SCR was 

generated. Field values are zero for a C-procsss, 1 
for an R-process, and 2 for a D-process. 
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AC1-3 

1 

3x1 

Contents of the 8-bit addressable counters assigned 
to the process. 

PMID 

4 

4 

Process model name if the process is a C-process. If 
the process is an R-process or D-process, the field 
contains the process source or device identifier in 
the low-order bytes. 

MSPC 

8 

2 

Number of M-spaces allocated by the process during 
the period covered by the SCR. 

BSPC 

10 

2 

Number of B-spaces allocated by the process during 
the period. 

MGTS 

12 

2 

Number of access control gates closed by the process 
during the period (zero for a D-process). 

NIOR 

14 

2 

Number of I/O requests made by the process during the 
period. 

NX1 


16 

2 Number of class 1 and class 2 process exceptions 
raised for the process during the period. 

NX3 

18 

2 

Number of class 3 and class 4 process exceptions 
raised for the process during the period. 

TPU 

20 

4 

Time in microseconds a processing unit was assigned 
to the process during the period. 

AC9-10 

24 

2x2 

Contents of the 16-bit addressable counters assigned 
to the process. 

AC13 

28 

4 

Contents of the 32-bit addressable counter assigned 
to the process. 
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Field 

PCL 

AC1-3 

PMID 

MSPC 

BSPC 

BSTG 

NX1 

NX3 

TPU 


PCL AC1 

AC2 AC3 

PMID 

MSPC 

BSPC 

BSTG 

NX1 

NX3 

TPU 

AC9 

AC10 

AC13 


Figure 10.10 
Process Family SCR Data 


Offset Bytes 


Description and Use 


0 1 


Class of the process model for which the SCR was gen¬ 
erated [Figure 10.9]. 


1 3x1 Contents of the 8-bit addressable counters assigned 

to the model. 

4 4 Process model name for a C-process model. For an 

R-process model or a D-process model, the field con¬ 
tains the process source or device identifier in the 
low-order bytes. 


8 2 Number of M-spaces allocated by processes of the fam¬ 

ily during the period covered by this SCR. 


10 2 Number of B-spaces allocated by processes of the fam¬ 

ily during the period. 

12 4 Number of kilobytes of B-storage required for 

B-spaces held in custody of the family during the pe¬ 
riod. 


16 2 Number of class 1 and class 2 process exceptions 

raised for processes of the family during the period. 


18 2 Number of class 3 and class 4 process exceptions 

raised for processes of the family during the period. 

20 4 Time in microseconds processing units were assigned 

to processes of the family during the period. 


' 4 .. 
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AC9-10 24 2x2 


Contents of the 16-bit addressable counters assigned 
to the model. 


AC13 28 4 


Contents of the 32-bit addressable counter assigned 
to the model. 



Figure 10.11 
Domain SCR Data 


Field 

Offset 

Bvtes 

Description and Use 


DNME 

0 

4 

Name of the domain for which the SCR was generated. 
The field is zero for the common domain. 

DID 

4 

4 

Identifier of the domain. 


CFRM 

8 

8 

System clock time when the domain was formed. 


MSPC 

16 

2 

Number of M-spaces admitted to the domain during 
period covered by this SCR. 

the 

BSPC 

18 

2 

Number of B-spaces admitted to the domain during 
period. 

the 

MSTG 

20 

4 

Number of bytes of M-storage used by members of 
domain during the period. 

the 


Chapter 10 


157 


System Inquiry Facilities 














Principles of Operation Version 1.0 

The EPSILON System 15 June 1976 


BSTG 24 4 Number of kilobytes of B-storage used by members of 

the domain during the period. 

ACPU 28 4 Time in microseconds a CPU was assigned to some pro¬ 

cess acting on behalf of the domain during the peri¬ 
od . 


APPU 32 4 Time in microseconds a PPU was assigned to some 

D-process acting on behalf of the domain during the 
period. 

AC1-4 36 4x1 Contents of the 8-bit addressable counters assigned 

to the domain. 


AC9-10 40 


2x2 Contents of the 16-bit addressable counters assigned 
to the domain. 


AC13 44 4 


Contents of the 32-bit addressable counter assigned 
to the domain. 


vide processes the ability to define 
groups of addressable statistical 
counters, to share the counters with 
other processes, and to display the 
value of any group of counters at any 
t i me. 

o The DEFINE STATISTICAL COUNTER 
GROUP instruction (D5CG), which 
can be executed within any C-pro- 
cess or R-process, will define a 
group of addressable statistical 
counters, provided M-storage is 
available and counter assignment 
is not suppressed. Assignment 
will be suppressed if bit 7 of 
the statistics collection mask 
is 1 and either bit zero or bit 6 
is zero. 

o If a group is defined, it becomes 
associated with the defining 
process as its current software 
group, and will be selected as 
such by a CSTAT instruction exe¬ 
cuted within the process 
[Section 10.31. The DSCG in¬ 
struction also returns a 16-bit 
identifier for the group, which 
can be retained by the process or 
passed to other processes. If a 


process executes an ACQUIRE STA¬ 
TISTICAL COUNTER GROUP instruc¬ 
tion (ASCG) specifying the 
identifier, the group becomes 
current for that process also. 
As in the case of other identifi¬ 
ers, zero is reserved for the 
identifier of a null group. An 
A5CG executed with zero as oper¬ 
and will return a process to the 
condition of having no effective 
software counter group current. 

o The STORE STATISTICAL COUNTER 
GROUP instruction (SSCG), which 
can be executed within any pro¬ 
cess, will store an SCR into a 
specified location. The counter 
group for the SCR is selected by 
the rules used for selecting 
counter groups for the CSTAT in- 
struction. 

The operand of a DSCG instruction is 
a 16-bit field which defines which of 
the possible types of addressable 
counters are to be contained in the 
group. Bits 1 through 15 correspond 
to the counters whose addresses with¬ 
in the group are designated by the 
address values 1 through 15 respec- 
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tively. If a bit is zero, the corre¬ 
sponding counter will not be included 
in the group; if the bit is 1, a 
counter of the appropriate length is 
assigned to that address. 

Bit zero of the operand determines 
the custody and access of the counter 
group defined by the instruction. If 
the bit is zero, the group is private 
to the process for both custody and 
access. An ASCG specifying the group 
executed within any other process 
will be rejected, and the group is 
deleted when the process terminates. 
If the bit is 1, the group is placed 
into family custody of the defining 
process; it can then be the legiti¬ 


mate subject of an ASCG instruction. 
A group in family custody is deleted 
when the process model is deleted. 
However, successful execution of an 
ASCG increments a reference count for 
the group, just as an LP does for a 
space. Group deletion will be de¬ 
layed until the reference count be¬ 
comes zero. 

When the contents of software coun¬ 
ters are made available on counter 
overflow or by execution of an SSCG 
instruction, the counter group is 
displayed in the SDTA field of the 
SCR in the format described in figure 
10 . 12 . 


CID 

CMSK 

AC1 

AC2 

AC3 

AC4 

ACS 

AC6 

AC7 

ACS 

AC9 

AC10 

AC11 

AC12 

AC13 

AC14 

AC15 


Figure 10.12 
Software SCR Data 


Field Offset Bytes 


Description and Use 


CID 0 2 Identifier of the software counter group for this 

SCR. 

CMSK 2 2 Mask supplied to the instruction which defined the 

group. The contents of any of the fields ACn in the 
record are meaningful only if the bit in this field 
corresponding to the counter is set to 1. 
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AC1-8 4 8x1 Contents of the 8-bit addressable counters assigned 

to the group. 


AC9-10 12 4x2 


Contents of the 16-bit addressable counters assigned 
to the group. 


AC13-14 20 2x4 


Contents of the 32-bit addressable counters assigned 
to the group. 


AC15 28 


Contents of the 64-bit addressable counter assigned 
to the group 


The SSCG instruction will generate an 
SCR of any type, not just a software 
SCR. The generated SCR can be stored 
at a given location or placed into 
the statistics or domain queues, 
forcing a system exception of that 
kind. 

o The instruction uses the RX foi— 
mat in which the R1 field speci¬ 
fies the type of group. The 
particular group within the 
specified type is selected by the 
modal conventions used for the 
CSTAT instruction. 

o If the R1 field contains a true 
type number, the SCR is stored at 
the location defined by the sec¬ 
ond operand. If the field value 
is a type number plus 8, the SCR 
is placed into the statistics or 
domain queue, as appropriate. 

An SCR generated by an SSCG instruc¬ 
tion has format identical to one gen¬ 
erated by a statistics event. For a 
given counter group, the content will 
also be the same except that field 
SCDC is set to the value 5 [Figure 
10.4]. However, counter values are 
not altered in any way as a result of 
generating an SCR by means of an SSCG 
instruction. 

10.8 Process Monitoring 

The process monitoring feature al¬ 
lows any process to specify condi¬ 


tions for which the activity of the 
process is to be monitored. If any 
of the conditions arise, a monitor 
trace record is generated, and the 
process is alerted to the condition 
by forcing a process exception with 
the trace information stored in field 
FRCE of the exception record [Figure 
5.4]. 

A C-process or R-process can be moni¬ 
tored for the following conditions: 

o execution of a linkage instruc- 
ti on 

o execution of a branch instruc¬ 
tion for which branching occurs 

o alteration of the contents of 
designated general registers 

o alteration of the contents of a 
designated M-space 

o excessive process time between 
execution of two monitor control 
instructions. 

A D-process can be monitored for 
linkage instructions, successful 
branches, and excessive time, but not 
for the other conditions. The pai— 
ticular conditions to be monitored 
are set up by execution of a SET MON¬ 
ITOR CONDITIONS instruction (SMC), 
which is supplied the monitoring in¬ 
formation in a Monitor Conditions 
Description Block (MCDB). An MCDB 
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must begin on a word boundary and 
have the format described in figure 
10.13. 

When the process monitoring feature 
is installed, the state vector of ev¬ 
ery process is enlarged to retain 
MCDB data, and to include a monitor 
mask which controls whether tracing 
for specified conditions is active or 
not. The bits of the mask correspond 
to the 

linkage, 

successful branch, 
pointer register, 
arithmetic register, 

M-space, and 
process time 

conditions, respectively, proceeding 
from high to low order bits. A bit 
of the mask must be 1 in order for 
tracing to be active for the condi¬ 
tion to which it corresponds. Howev¬ 
er, the action of the process 
monitoring mechanism in relation to a 
process is governed primarily by bit 
zero of field PFLG of the PIC. 

o If the monitor bit of the PIC is 
zero, process activity is not 
monitored at all. No monitor 
exceptions will be forced, nor 
will instruction execution time 
for the process be affected. 

o If the monitor bit is 1, instruc¬ 
tion execution within the pro¬ 
cess is monitored for occurrence 
of the conditions set up by the 
last SMC instruction executed by 
the process. Process activity is 
monitored even if no SMC has yet 
been executed, so that instruc¬ 
tion execution time is always 
lengthened when the monitor bit 
i s on. 

o If the monitor bit is on and a 
specified condition occurs, a 
trace record is generated if the 
monitor mask bit corresponding 


to the condition is 1. The re¬ 
cord is not generated if the mask 
bit is zero, nor is the process 
exception forced. 

The SMC instruction will also turn on 
or off the monitor bit of the PIC, 
and turn on or off all bits of the 
monitor mask as a group. Consequent¬ 
ly, if all conditions are to be 
treated uniformly, it is possible to 
set up monitoring conditions and mon¬ 
itoring activity with a single in¬ 
struction. If conditions are to be 
treated selectively, individual mon¬ 
itor bits can be altered with the SET 
MONITOR MASKS instruction (SMM). SMM 
exchanges both the monitor mask and 
the monitor bit of the PIC for a mask 
byte in the instruction. 

As process monitoring is considered 
to be a diagnostic aid which should 
not interfere with normal process ac¬ 
tivity, a process monitor exception 
is suppressed in favor of any other 
process exceptions raised by an in¬ 
struction. Moreover, when a monitor 
exception is forced the new PIC on 
entry to the exception module is set 
with monitor bit zero. The exception 
module is free to turn the monitor 
bit on, but if a monitor exception is 
forced during this time it will ef¬ 
fectively be ignored [Section 5.133. 

The extension of the exception record 
forced by a monitor exception, corre¬ 
sponding to field FRCE in figure 5.4, 
has the format described in figure 
10.14. The CDATn fields of the exten¬ 
sion contain the following informa¬ 
tion. 

o For a linkage exception, CDAT1 
contains a pointer to the M-space 
from which the CALL or RETURN was 
was executed, and CDAT2 contains 
the address of the instruction 
within the space. 


o For a branch exception, CDAT1 
contains a pointer to the M-space 
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Fi eld 
WDTM 

PRM 

ARM 

SPCE 


Field 

CDAT1 

MMS 



Figure 10.13 

Monitor Conditions Description Block 


Offset Bytes Description and Use 

0 4 Maximum process time in microseconds between succes¬ 

sive executions of an SMC instruction by the process. 
The time is measured only while a processing unit is 
assigned to the process. 


4 2 Defines the pointer registers which are to be moni¬ 

tored for alteration. Bits 0 to 15 correspond to reg- 
i sters 0 to 15. A register is to be monitored if its 
corresponding bit is 1. 

6 2 Defines the arithmetic registers to be monitored for 

alteration. Bit conventions are the same as for 
field PRM. 


8 4 


A pointer to an M-space which is to be monitored for 
alteration. 


CDAT1 

MMB 

CDAT2 


Figure 10.14 

Extension of Exception Record 
Forced by Monitor Exception 


Offset Bytes Description and Use 

0 4 Contains data pertinent to the condition which caused 

the exception to be forced. 

4 1 Bits which indicate the condition that caused the ex¬ 

ception to be forced. The first six bits correspond 
to the bits of the monitor mask. The trigger condi¬ 
tion is indicated by which one of these bits is set to 
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1. The last two bits of the field are zero. 

CDAT2 5 3 Contains data pertinent to the condition which caused 

the exception to be forced. 


within which the branch instruc¬ 
tion is located, and CDAT2 con¬ 
tains the address of the instruc¬ 
tion. If the branch was caused 
by an EXECUTE instruction, the 
fields locate that instruction. 

o For a pointer or arithmetic regi¬ 
ster exception, CDAT1 contains 
the value of the register prior 
to alteration. Field CDAT2 is 
not significant. 

o For an M-space exception, CDAT1 
contains a pointer to the space 


and CDAT2 contains the address 
within the space of the data 
which was accessed. 

o Neither field has significance 
for an excessive time exception. 

As with any class 3 exception, a mon¬ 
itor trace record is stored after the 
state vector is updated on completion 
or termination of the instruction. 
In each case, therefore, the old and 
new data values are available to the 
exception module. 


10.9 Instruction Descriptions 


STORE CONFIGURATION DATA 


SCONS Ml,D2(X2,B2) <RX> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. If the instruction is 
not suppressed, configuration data is stored at the specified location. 

The first operand serves as a mask field which selects the options 
specifiable with the instruction. If the high-order bit of the mask is zero, 
a CDB is stored at the location; if the bit is 1, no CDB is stored. If a CDB is 
stored, bit 1 determines its content. If the bit is zero, the CDB describes 
installed onditions; if the bit is 1, the CDB describes current availability. 

If bit 2 of the mask is zero, a computation cycle list is stored; if the 
bit is 1, no list is stored. Computation cycle identifiers are stored in 
succesive byte locations, starting at the location immediately following the 
CDB, or at the location specified by the second operand if no CDB is stored. A 
complete list of identifiers is stored if the high-order bit of mask field Ml 
is zero. If the bit is 1, the list contains only the identifiers of those cy¬ 
cles with an active process. In either case, the identifiers are stored in 
order of decreasing response priority. 
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Process Class: C,R 

Condition Code: Unchanged 

Exceptions: 

Specification 

STORE PROCESS MODEL LIST 


Principles of Operation 
The EPSILON System 


SPML R1,D2(X2,B2) <RX> 

C-process model names are stored in successive words starting at the sec¬ 
ond operand location, up to the number of words specified by the value con¬ 
tained in arithmetic register Rl. Subsequently the content of the register is 
replaced by the difference between its original value and the number of C-pro- 
cess models in the system. 

Names are stored in arbitrary order. If storing a name would require ex¬ 
ceeding the space boundary, the instruction is terminated at that point with 
condition code 3, and without decrementing register Rl. If the instruction is 
completed, the condition code is set according to the final value of register 
Rl. 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. 

Process Class: C 

Condition Code: 

0 Difference is zero 

1 Differencee is negative 

2 Difference is positive 

3 Insufficient space allowed 

Exceptions: 

Specification 


STORE DOMAIN LIST 


SDOL Rl,D2CX2,B2) <RX> 

Pairs of domain names and identifiers are stored in successive 
double-words starting at the second operand location, up to the number of 
double-words specified by the value contained in arithmetic register Rl. Sub¬ 
sequently the content of the registar is replaced by the difference between 
its original value and the number of domains in the system. 

The name of the domain is stored in the first word of a pair, followed by 
the identifier in the second word. The pair corresponding to the common do¬ 
main is stored first; the remaining pairs are stored in arbitrary order. If 
storing a pair would require exceeding the space boundary, the instruction is 
terminated at that point with condition code 3, and without decrementing regi- 
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ster Rl. If the instruction is completed, the condition code is set according 
to the final value of register Rl. 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. 


Process Class : C 

Condition Code : 

0 Difference is zero 

1 Difference is negative 

2 Difference is positive 

3 Insufficient space allowed 

Exceptions: 

Specification 


STORE QUEUE STATUS 


SQS Rl,D2(B2) <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is terminated with 
condition code 1 if arithmetic register Rl does not contain the q.ix of an ex¬ 
isting queue. 

If the instruction is not suppressed or terminated, a queue status record 
for the specified queue is stored at the second operand location. The in¬ 
struction is then completed with condition code zero. 

Process Class-' C 

Condition Code : 

0 Status record stored 

1 Invalid queue index 

2 

3 

Except ions: 

Specificattion : 


STORE COMPUTATION CYCLE RECORD 


SCCR R1,D2(B2) <RS> 

The instruction is suppressed with a specification exception if the second 
operand does not define a location on a word boundary. It is terminated with 
condition code 1 if arithmetic register Rl does not contain the identifier of 
an existing computotiion cycle. 

If the instruction is not suppressed or terminated, a computation cycle 
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status record for the specified cycle is stored at the second operand loca¬ 
tion. The instruction is then completed with condition code zero. 

Process Class 1 C 

Condition Code: 

0 Status record stored 

1 Invalid cycle identifier 

2 
3 

Exceptions: 

Specification 


COLLECT STATISTICS 


CSTAT I1,I3,D2(B2) <RS> 

The instruction is terminated immediately with condition code zero if bit 
zero of the statistics collection mask is zero. If the bit is 1 the value in a 
statistical collection counter is incremented or replaced by the value of the 
integer found at the second operand location. 

Immediate fields II and 13 specify the counter to be modified and the mod¬ 
ification action. If the value of field 13 is between 0 and 7, the counter is 
to be incremented, otherwise the counter value i s to be replaced. 

The counter group containing the counter to be modified is selected ac¬ 
cording to the value of field 13 modulo 8. If the value is zero, a null coun¬ 
ter group is selected. If the value is 1, and if bit 1 of the statistics 
collection mask is zero, the instruction is terminated with condition code ze¬ 
ro. If the bit is 1, and if the process executing the instruction is a D-pro- 
cess, the counter group selected is the group assigned to the I/O device with 
which the process is associated. A null group is selected if counter assign¬ 
ment was suppressed for the device, or if the instruction is being executed 
within a C-process or R-process. 

If the value of field 13 modulo 8 is 2, and if bit 2 of the statistics col¬ 
lection mask is zero, the instruction is terminated with condition code zero. 
If the bit is 1 and if the process executing the instruction is an R-process, 
the counter group selected is the group assigned to the process source of the 
process. A null group is selected if counter assignment was suppressed for 
the source, or if the instruction is being executed within a C-process or 
D-process. 

If the value of field 13 modulo 8 is 3, and if bit 3 of the statistics col¬ 
lection mask is zero, the instruction is terminated with condition code zero. 
If the bit is 1 and if the process executing the instruction is a C-process, 
the counter group selected is the group assigned to the current queue of the 
process. A null group is selected if the process does not have a queue cui— 
rent, if counter assignment was suppressed for the queue, or if the instruc¬ 
tion is being executed within an R-process or D-process. 

If the value of field 13 modulo 8 i s 4 or 5, and if bit 4 of the statistics 
collection mask is zero, the instruction is terminated with condition code ze¬ 
ro. If the bit is 1 and the value is 4, the group selected is the group as- 
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signed to the process within which the instruction is being executed. If the 
value is 5 the group selected is the group assigned to the process model for 
the process. A null group is selected if counter assignment was suppressed 
for the process or process model. 

If the value of field 13 modulo 8 is 6, and if bit 5 of the statistics col¬ 
lection mask is zero, the instruction is terminated with condition code zero. 
If the bit is 1, the group selected is the group assigned to the domain on 
whose behalf the process executing the instruction is currently acting. A 
null group is selected if counter assignment was suppressed for the domain. 

If the value of field 13 modulo 8 is 7, and if the software statistics fea¬ 
ture is not installed on the system or if bit 6 or the statistics collection 
mask is zero, the instruction is terminated with condition code zero. If the 
bit is 1, the counter group selected is the software group current for the 
process within which the instruction is being executed. A null group is se¬ 
lected if there is no such group current for the process. 

If a null group is selected, the instruction is terminated with condition 
code 2. If the group is not null, field II is examined to determine the coun¬ 
ter within the group which is to be modified. If the field value designates a 
counter not contained in the selected group, the instruction is terminated 
with condition code 2. If the designated counter is contained in the group, 
it is modified by the contents of the field which begins at the second operand 
location and extends through as many bytes as equal the length of the counter 
to be modified. 

The instruction is completed with condition code 1 if the counter is 
loaded with a value, or if it can be incremented without overflow. If incre¬ 
menting would cause overflow, the counter is set to its maximum value, a coun¬ 
ter overflow SCR is generated, and a statistics collection system exception is 
raised by placing the SCR into the statistics collection queue. All counters 
of the selected group are then reset to zero, and the instruction is completed 
with condition code 3. 

Process Class 1 C,R,D 
Modal 


Condition Code: 

0 Statistics not being collected 

1 Counter modified 

2 Null counter selected 

3 Counter overflow 


Exceptions= 

Statistics collection (system) 


SET COLLECTION MASK 


SCM D1(B1),12 <SI> 

The current value of the statistics collection mask is stored at the loca¬ 
tion specified by the first operand. The instruction is then terminated with 
condition code 1 if bit 7 of the mask is 1. If the bit is zero, the mask is set 
equal to the byte of immediate data in the second operand field, and the in- 
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struction is completed with condition code zero. 

Process Class: C,R 

Condition Code: 

0 Mask value reset 

1 Mask cannot be altered 

2 
3 

Exceptions: None 


DEFINE STATISTICAL COUNTER GROUP 


DSCG R1,D2(X2,B2) <RX> 

The instruction is suppressed with an operation exception if the software 
statistics feature is not installed on the system. It is terminated with con¬ 
dition code 1 if bit 7 of the statistics collection mask is 1 and either bit 
zero or bit 6 is zero. 

If the instruction is not suppressed or terminated, an attempt is made to 
obtain M-storage for a complete set of addressable statistical counters. The 
instruction is terminated with condition code 2 if storage is not available. 
If storage is available, counter positions whose addresses correspond to bit 
positions 1 through 15 of the 16-bit field located by the second operand are 
marked active if the bit is 1 and inactive if the bit is zero. 

If bit zero of the field located by the second operand is zero, the coun¬ 
ter group is placed into custody of the process within which the instruction 
is being executed and marked private. If the bit is 1, the group is placed in¬ 
to custody of the process family. 

An identifier for the group is generated and placed into arithmetic regi¬ 
ster Rl, the group is assigned as the current software group of the process, 
and the instruction is completed with condition code zero. 

Process Class: C,R 

Condition Code: 

0 Counters assigned 

1 Assignment suppressed 

2 Storage not available 

3 

Except ions: 

Operation 


-r 


t " 

V. 
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ACQUIRE STATISTICAL COUNTER GROUP 


ASCG R1 <RR> 

The instruction is suppressed with an operation exception if the software 
statistics feature is not installed on the system. It is terminated with con¬ 
dition coda 2 if arithmetic register R1 does not contain the identifier of a 
software statistical counter group. If the identifier is valid, the instruc¬ 
tion is terminated with condition code 1 if the group is in private custody of 
a process other than the process within which the instruction is being exe¬ 
cuted . 

If the instruction is not suppressed or terminated, and if the process has 
a software counter group current, the reference count of that group is decre¬ 
mented by 1. The group referenced by register R1 is then made the current 
software group of the process, its reference count is incremented by 1, and 
the instruction is completed with condition code zero. 

Process Class 1 C,R,D 

Condition Code 1 

0 Group acquired 

1 Group not available 

2 Invalid group identifier 

3 

Exceptions : 

Operation 


STORE STATISTICAL COUNTER GROUP 


SSOG I1,D2(X2,B2) <RX> 

The instruction is suppressed with an operation exception if the software 
statistics feature is not installed on the system. It is suppressed with a 
specification exception if the second operand does not define a location on a 
word boundary. 

If the instruction is not suppressed, immediate field II specifies the 
type of SCR to be generated and the store action for the SCR. If the value of 
field II is between 0 and 7, the SCR is to be stored at the second operand lo¬ 
cation, otherwise the SCR is to be placed into the statistics or domain excep¬ 
tion queue, as appropriate. 

The counter group for the SCR is selected according to the value of field 
II modulo 8. If the value is zero, the instruction is terminated with condi¬ 
tion code 2. If the value is 1, and if the process executing the instruction 
is a D-process, the group selected is the group assigned to the I/O device 
with which the process is associated. The instruction is terminated with con¬ 
dition code 2 if the device has no counter group assigned, or if the instruc¬ 
tion is being executed within a C-process or R-process. 

If the value of field II modulo 8 is 2, and if the instruction is being ex- 
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ecuted within an R-process, the counter group selected is the group assigned 
to the process source for the process. The instruction is terminated with 
condition' code 2 if the source has no counter group assigned, or if the in¬ 
struction is being executed within a C-process or D-process. 

If the value of field II modulo 8 is 3, and if the process is being exe¬ 
cuted within a C-process, the counter group selected is the group assigned to 
the current queue of the process. The instruction is terminated with condi¬ 
tion code 2 if the process has no current queue, if the queue has no group as¬ 
signed, or if the instruction is being executed within an R-process or 
D-process. 

If the value of field II modulo 8 is 4, the counter group selected is the 
group assigned to the process executing the instruction. If the value is 5, 
the group selected is the group assigned to the process model for the process. 
If the value is 6, the group selected is the group assigned to the domain on 
whose behalf the process is currently acting. If any of these groups is a null 
group, the instruction is terminated with condition code 2. 

If the value of field II modulo 8 is 7, the counter group selected is the 
group assigned as the current software group of the process executing the in¬ 
struction. The instruction is terminated with condition code 2 if the process 
has no current software group. 

An SCR is generated for the selected group. If the SCR is stored at the 
second operand location, the instruction is completed with condition code ze¬ 
ro. If the SCR is to be enqueued, it is placed into the domain exception queue 
if the value of field II modulo 8 is 6, otherwise it is placed into the statis¬ 
tics exception queue. The instruction is then completed with condition code 
1 . 


Process Class 1 C,R,D 
Modal 


Condition Code 1 

0 SCR stored 

1 SCR enqueued 

2 Null group selected 

3 

Except ions: 

Operation 
Specification 
Statistics (system) 
Domain (system) 


SET MONITOR CONDITIONS 


SMC Ml,D2(X2,B2) <RX> 

The instruction is suppressed with an operation exception if the process 
monitoring feature is not installed on the system. It is suppressed with a 
specification exception if the second operand does not define a location on a 
word boundary. 

If the istruction is not suppressed, the information in the MCDB located 
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by the second operand replaces the monitor conditions current for the process. 
The entire block is used if the instruction is being executed within a C-pro- 
cess or R-process. For a 0-process, only the first word of the block is used. 

Mask field Ml is examined for monitor mask action. If bit zero of field Ml 
is zero, the monitor mask is not disturbed. If the bit is 1, all bits of the 
monitor mask are set to the value of bit 1 of field Ml. If the value of the 
process time bit of the monitor mask is changed by this action, the process 
time counter for the process is set to the value in field WDTM of the MCDB lo¬ 
cated by the second operand. 

If bit 2 of field Ml is zero, the instruction is completed with condtition 
code 2. If the bit is 1, the monitor bit of the PIC is set to the value of bit 
3 of field Ml. If the new value of the monitor bit is zero, monitor probes for 
the process are deactivated, and the instruction is completed with condition 
code zero. If the monitor bit of the PIC is 1, monitor probes are activated, 
and the instruction is completed with condition code 1. 

Process Class : C,R,D 
Modal 


Condition Code: 

0 Monitoring deactivated 

1 Monitoring activated 

2 Monitoring not changed 

3 

Except ions: 

Operation 
Specification 


SET MONITOR MASKS 


SMM D1(B1),I2 <SI> 

The instruction is suppressed with an operation exception if the process 
monitoring feature is not installed on the system. If the instruction is not 
suppressed, the value of the monitor bit of the PIC and the current monitor 
mask of the process are stored in the byte located by the first operand. Bit 
zero of the byte is set to the value of the monitor bit, bits 1 through 6 with 
the value of the monitor mask, and bit 7 is set to zero. 

The monitor bit of the PIC is then set equal to the value of bit zero of 
immediate field 12, the bits of the monitor mask of the process are set equal 
to bits 1 through 6 of field 12, and the instruction completion sequence is 
entered. 

The instruction completion sequence compares the value of bit 6 of the 
byte stored at the second operand location with the value of the process time 
bit of the new monitor mask. If the bit values are unequal, the process time 
counter for the process is set to the value of field WDTM of the current MCDB 
of the process. The counter is set to its maximum value if there is no MCDB 
current. If the bit values are equal, the process time counter is not dis¬ 
turbed . 

If the new monitor bit of the PIC is 1, monitor probes for the process are 
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activated, and the instruction is completed with condition 
is zero, the probes are deactivated, and the instruction 
condition code zero. 

Process Class: C,R,D 

Condition Code: 

0 Monitoring deactivated 

1 Monitoring activated 

2 
3 

Exceptions= 

Operation 
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code 1. If the bi t 
is completed with 


Chapter 10 


172 


System Inquiry Facilities 



Principles of Operation 
The EPSILON System 


Versi on 1 . 0 
15 June 1976 


11.0 MALFUNCTION DETECTION AND RECOVERY 


Mechanisms for the detection and coi— 
rection of errors caused by malfunc¬ 
tion of hardware or microcode vary in 
form and capability from one model of 
EPSILON system to another. Some mod¬ 
els, for example, employ bit encoding 
techniques for storage that permit 
correction of all single-bit fail¬ 
ures, while others are able to detect 
but not correct such failures. All 
models, however, follow the same bas¬ 
ic procedure when an error condition 
is detected. 

o If the detection mechanism is ca¬ 
pable of correcting the condi¬ 
tion, a local correction is 
applied. The detection mech¬ 
anism may then log error cor¬ 
rection data, but will take no 
further action. 

o If local correction is not possi¬ 
ble, information describing the 
error condition is transmitted 
to an error recovery process. 
For many errors, the recovery 
process is an internal system 
process responsible for analysis 
and correction of a class or type 
of error. 

o If there is no internal recovery 
process, or if that process can¬ 
not effect recovery, a system 
error signal is raised. The ei— 
ror signal is a process source 
for a family of service processes 
which respond to error condi¬ 
tions the system cannot handle. 
An error signal process may dis¬ 
pose of an error report in any 
manner, and may trigger orderly 
system termination if the condi¬ 
tion precludes useful continued 
operation. 

A system error signal is raised only 
for an actual system malfunction, not 
for programming errors. If an inval¬ 


id data format or incorrect use of an 
instruction is detected, the error is 
reported by signalling a process ex¬ 
ception. Conditions which might lead 
to a deviation from normal for pro¬ 
cess behavior in general, are re¬ 
ported by signalling a system 
exception. Errors detected by soft¬ 
ware are reported by forcing either a 
process or system exception. This 
chapter describes the kinds of system 
malfunction detected, the internal 
recovery attempted, and the facili¬ 
ties available to error signal pro¬ 
cesses. 

11.1 Hardware Malfunction 

Behavioral malfunctions of hardware 
are detected by encoding redundant 
bits in storage, or employing redun¬ 
dant circuitry in active components. 
All replaceable units (RU) of EPSILON 
systems include enough redundancy to 
determine whether or not a malfunc¬ 
tion detected within the unit is the 
fault of the unit itself. The set of 
RU for a system is model-dependent, 
but the CPU, PPU, and Basic Storage 
Modules (BSM) are always RU. 

If an RU detects an error condition 
it cannot correct, it is said to have 
sustained damage; if the error is 
corrected the RU has effected recov¬ 
ery. An RU which effects recovery may 
generate a recovery report error 
signal as a means of noting the cot— 
rection if not itself capable of such 
action. An RU which sustains damage 
is removed from the active configura¬ 
tion of the system, and some type of 
error signal is raised. 

o If the RU is replicated, and if 
it is not the sole remaining ac¬ 
tive member of its set, a degra¬ 
dation report is generated. 

o If the RU is not replicated, or 
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if its peers have all been previ¬ 
ously damaged, a darcaga report is 
generated. If system operation 
cannot reasonably continue with¬ 
out the damaged RU Ce.g. the last 
CPU failed), primary damage is 
reported, otherwise the damage 
is secondary. 

An environmental or operational mal¬ 
function, such as low voltage, loss 
of cooling, or power failure, which 
causes or may cause behavioral er¬ 
rors, is reported by means of a warn¬ 
ing report. Warning reports are 
generated by any RU which detects the 
condition. 

11.2 invalid System Data 

Internal data required for system op¬ 
eration resides in M-storage in the 
form of control blocks and control 
block lists. Data values are checked 
for validity by microcode to the ex¬ 
tent practical for a given model. 
Critical data items in the 

computation cycle list, 
space allocation list, 
process state vectors, 
process model definitions, 
queue control list, 
gate control list, and 
device descriptions 

are checked on all models. Some form 
of error signal is raised whenever 
system data is found to be inconsist¬ 
ent or invalid. 

o If the data can be reconstructed, 
the error is signalled by a re¬ 
covery report. Reconstruction 
is possible only on models which 
preserve redundant system data. 

o If a substitute value can be used 
without affecting the immediate 
behavior of any process, the ei— 
ror is signalled by a warning re¬ 
port. For example, if queue 
header data is found to be inval¬ 


id, the queue can be treated as a 
null queue without inducing be¬ 
havioral defects in the attend¬ 
ant or enqueuing processes. 
However, as in the case of hard¬ 
ware, warning reports signal the 
certaintly of future damage. 

o If reconstruction or substi¬ 
tution is not possible, the error 
is signalled by a damage report. 
Primary damage is reported if the 
invalid data prevents normal op¬ 
eration of the system Ce.g. in¬ 
valid gate data prevents 
R-process dispatching). Second¬ 
ary damage is reported if the ei— 
ror is limited to a particular 
process or set of processes. 

Reconstruction, substitution, or by¬ 
passing of invalid data allows pro¬ 
cess activity to continue when a 
recovery report, warning report, or 
secondary damage report is sig¬ 
nalled. However, if primary damage 
is reported, all process activity is 
suspended except for any error signal 
process intiated by the report. 

11.3 System Operation Error 

Although the microinstruction set is 
model-dependent, the equivalent of a 
microprocess exception can occur on 
all models. If an exception micro¬ 
routine attributes such an exception 
to invalid data in the registers or 
local storage of a CPU or PPU, the 
exception is treated as a malfunction 
of that RU [Section 11.1]. RU mal¬ 
function is also signalled if a 
microinstruction sequence private to 
the CPU or PPU is judged to be at 
fault. 

If a faulty microinstruction se¬ 
quence is shared by the processing 
units of a system, a damage report is 
generated. 

o Primary damage is reported if the 
fault impairs the interpretation 


1 - 
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of any instruction standard to 
the basic, computational, or pe¬ 
ripheral instruction sets. 

o Secondary damage is reported if 
the fault impairs the interpre¬ 
tation of an instruction in some 
feature set, and the feature set 
is made unavailable. Any process 
can determine feature availabil¬ 
ity by storing a configuration 
description block [Figure 10.1]. 

Error signals are also raised for un¬ 
recoverable internal I/O errors on 
data transfer between M-storage and 
B-storage. These will be reported as 
hardware malfunction if the error is 
attributed to some RU, and as system 
operation damage if the microin¬ 
struction sequence is judged to be at 
fault. If the error occurs for an 
instruction for which a 'space not 
available' condition code return is 
possible (e.g. LOAD, SAVE, DCPM), 
that code is returned to the process 
executing the instruction. If the 
error occurs for a CALL instruction 
executed within a C-process, an ac¬ 
cess exception is raised when the 
process is removed from I/O wait dis¬ 
patching condition. 

11.4 Error Signal Mask 

The setting of the error signal mask, 
which is displayed in field ERSM when 
a configuration description block is 
stored [Figure 10.13, determines 
whether or not an error signal actu¬ 
ally triggers the error signal pro¬ 
cess source. 

o Bit zero of the mask is the mas¬ 
ter switch. If the bit is zero, 
all system error signals are 
ignored. Error reports are dis¬ 
carded, and no error signal pro¬ 
cesses will be initiated. If the 
bit is 1, error signals are ef¬ 
fective, subject to the remain¬ 
ing bits of the mask. 


o Bits 1 through 5 are switches for 
primary damage, secondary dam¬ 
age, degradation, warning, and 
recovery report error signals, 
respectively. If a bit is zero, 
signals of the type it controls 
are ignored. If a bit is 1, 
signals of that type are effec¬ 
tive, and will trigger the error 
signal process source. 

o Bit 6 is the checkpoint control 
switch. If the bit is zero, a 
checkpoint request is honored 
only within an error signal pro¬ 
cess. If the bit is 1, any 
R-process can trigger a system 
checkpoint [Section 12.83. 

o Bit 7 determines whether or not 
the value of the mask can be 
changed. If the bit is zero, the 
mask can be set to another value; 
if the bit is 1, the mask value 
cannot be changed. 

The initial value of the error signal 
mask is specified at system initial¬ 
ization. If bit 7 is then zero, the 
mask can be set to another value by 
execution of the SET ERROR MASK in¬ 
struction (SRM) within any C-process 
or D-process. 

If an error signal is raised when the 
master switch bit is off, or when the 
master switch bit is on but the bit 
which controls the type of error re¬ 
ported is off, system activity con¬ 
tinues if at all possible. However, 
the system termination procedure is 
invoked if system damage is so severe 
that activity cannot continue. Sys¬ 
tem termination will signal an ex¬ 
ternal alarm, attempt to checkpoint 
system data, and stop all CPU, PPU, 
and I/O activity [Chapter 123. 

11.5 Error Signal Processes 

The process model connected to the 
error signal process source is an 
R-process model whose RMDB contains 
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Field 

ESCE 


Field 

SDFN 


ESCE 


SDFN 


MDEP 


Figure 11.1 
Error Report 


Offset Bvtes 


Description and Use 


0 1 


Bits which define the type and source of the error re¬ 
port 


Bit Value 


Si qnificance 


0 


0 

1 


Normal 

This is a primary damage report 


1 


0 

1 


Normal 

This is a secondary damage report 


2 


0 

1 


Normal 

This is a degradation report 


3 


0 

1 


Normal 

This is a warning report 


4 


0 

1 


Normal 

This is a recovery report 


5 


0 

1 


Normal 

This report was generated because of a hardware mal- 
function 


6 


0 

1 


Normal 

This report was generated because of invalid system 
data 


7 


0 

1 


Normal 

This report was generated because of a system oper 
ation error. 


Offset Bvtes Description and Use 

1 1 Bits which define the source which caused the report 

to be generated. The significance of each bit varies 
with the type of source. In the following descrip¬ 
tion, numbers in parentheses indicate the source type 
to which a statement is applicable: (1) indicates 
hardware malfunction, (2) indicates invalid system 
data, and (3) indicates system operation error. If a 
statement has no source type numbers attached, it ap¬ 
plies to all source types. 
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Bit Value 

0 0 
1 


1 0 
1 


2 0 
1 


3 0 

1 


4 0 

1 


5 0 

1 


6 0 
1 


7 0 

1 


Sianificance 


Normal 

Reported by a CPU (1) 

Computation cycle list (2) 

Power abnormality (3) 

Normal 

Reported by a PPU Cl) 

Space data or space allocation(2 ) 

Power failure (3) 

Normal 

BSM affected Cl) 

Process state vector C2) 

Cooling system failure C 3) 

Normal 

System clock affected Cl) 

Process model definition block C2) 

Reserved C 3) 

Normal 

Queue header or queue control C2) 

Reserved Cl,3) 

Normal 

Gate or gate control list C2) 

Reserved Cl,3) 

Normal 

Device description C2) 

Reserved Cl,3) 

Normal 

A source other than one specifically identified by 
the other bits 


Fi eld Offset Bytes Description and Use 

MDEP 2 2 Data which depends on source and model. The field is 

described in the functional specifications of each 
EPSILON system model. 


the following data. 

o The bits of field RMFLG are set 
so that 


the domain identifier for 
processes of the family is 
the identifier of the entry 
context space 


process statistics are not - the process model is 

collected 
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single-instance, and is in 
system custody. 

o The module M-space identified fay 
field RMMOD is specified at sys¬ 
tem initialization/ and bound to 
the custody of the model; fields 
RMLOC and RMMSK are set to zero. 
A null exception module is speci¬ 
fied by field RMXMD. 

o The entry context space is speci¬ 
fied at system initialization. 

The error signal process source is 
assigned a dispatching priority 
higher than any other R-process 
source/ so that an attempt is made to 
initiate an error signal process as 
soon as an error signal becomes ef¬ 
fective. The system termination pro¬ 
cedure will be invoked if system 
damage is so severe that a process 
cannot be initiated. System termi¬ 
nation will also be invoked if an ei— 
ror signal process is itself 
terminated by any means other than 
execution of an EXIT instruction. 

If a process is initiated/ the error 
report becomes the communication da¬ 
ta placed into arithmetic register 1 
at entry to the process. The format 
of an error report is described in 
figure 11.1. An error signal process 
may respond to the error report with 
any kind of activity allowed to an 
R-process. If the process terminates 
with an EXIT instruction/ the impli¬ 
cation is that damage is not exten¬ 
sive enough to warrant shutdown of 


the system. If system operation is 
to be shutdown/ the error signal pro¬ 
cess can output system restart data 
with a CHECKPOINT instruction and ap¬ 
plication or installation restart 
data using normal I/O operations. 
The process can also trigger logout 
of data to be analyzed to determine 
the cause of failure. 

Some diagnostic data is generated for 
every error signal. If a CPU, PPU, 
or BSM sustains damage, error logout 
data is placed into a reserved area 
of M-storage before the RU i s removed 
from the active configuration of the 
system. Data may also be placed into 
the logout area by microcode prior to 
generation of a damage report, and by 
execution of a DIAGNOSE instruction. 

DIAGNOSE is a special instruction 
which can be executed only within an 
error signal process. It will logout 
diagnostic data and then invoke sys¬ 
tem termination. No operand is spec¬ 
ified, as the type of data to be 
placed into the logout area is deter¬ 
mined by the error report which ini¬ 
tiated the process within which the 
instruction is executed. The specif¬ 
ic data logged for a given type of 
error report is model-dependent, and 
each model has its own diagnostic 
microroutine to analyze data stored 
in the logout area. These routines, 
which can be executed only when the 
system is in diagnostic mode, are de¬ 
scribed in the functional charactei— 
isties document for each model. 


11.6 instruction Descriptions 


SET ERROR MASK 


SRM D1CB1),I2 <SI> 

The current value of the error signal mask is stored into the byte located 
by the first operand. The instruction is then terminated with condition code V 
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1 if bit 7 of the mask is 1. If the bit is zero, the mask is set equal to the 
byte of immediate data in the second operand field, and the instruction is 
completed with condition code zero. 

Process Class: C,R 

Condition Code: 

0 Mask value reset 

1 Mask value cannot be reset 

2 
3 

Exceptions: None 


DIAGNOSE 


DIAGNOSE - <RR> 

The instruction is suppressed with an operation exception if the process 
within which it is being executed is not an error signal process. 

If the instruction is not suppressed, error logout data corresponding to 
the error report being serviced by the process is placed into the diagnostic 
logout area, and the instruction is completed by invoking the system termi¬ 
nation procedure. 

Process Class 1 R 

Condition Code: Unchanged 

Exceptions : 

Operation 
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12.0 SYSTEM INITIALIZATION 

System initialization is the activ¬ 
ity of bringing a system into produc¬ 
tive operating condition after power 
is turned on, or after system opei— 
ation has been terminated for any 
reason. The particular operating 
condition achieved is determined by 
the content of the Initialization Da¬ 
ta Table (IDT) supplied as input to 
the initialization procedure. 

An IDT contains all the configuration 
data, initial space data, process 
model definition blocks, and system 
parameter values necessary to speci¬ 
fy an operational state correspond¬ 
ing to the desired operating 
condition. The initialization pro¬ 
cedure is a sequence of steps which 
carries the system from its initial 
operational state to the state 
defined by the IDT. Because IDT can 
be prepared at any time, system in¬ 
itialization is equally capable of 
producing states which correspond to 
initial startup following delivery 
or to a restart from some checkpoint. 

12.1 Overview 

System initialization is invoked 
from the operator console by desig¬ 
nating an input device with the 
device-identifier switches and then 
depressing the initialization key. 
On some models it is possible to at¬ 
tach an I/O device so that it can 
transmit a signal which duplicates 
that of the initialization key. In 
either case, the initialization 
signal is effective only if the sys¬ 
tem has been reset to initial opera¬ 
tional state. 

Initial state is entered at the end 
of a powei—on sequence, as the final 
step of system termination, or when 
the system is reset as a result of 
depressing the system reset key on 
the operator console. In the initial 


state, process models are not con¬ 
nected to sny process source, the 
system data areas are clear, instruc¬ 
tion i nterpretation by CPU and PPU is 
suspended, and I/O reset has been 
signalled to all devices attached to 
the system. Consequently, there is 
no process activity, and none can be 
initiated until the initialization 
procedure has been completed. 

When an initialization signal be¬ 
comes effective, the IDT is loaded 
into M-storage from the initializa¬ 
tion device. If the console switches 
are set to the null device (identifi¬ 
er zero), the IDT is obtained from an 
area in B-storage set aside for in¬ 
itialization data. The area is sup¬ 
plied at the factory with a basic 
startup IDT, and is replaced during 
each operational period with an IDT 
which provides continuity of opei— 
ation from one operational period to 
the next. If the console switches 
are set to a real device, the IDT is 
loaded by a special microprogram se¬ 
quence executed by a PPU through 
which the device is attached to the 
system. If the device is passive 
(e.g. tape unit or disc), it is as¬ 
sumed to be properly positioned for 
input; if the device is active (e.g. 
another computer system), it is ex¬ 
pected to be able to transmit IDT re¬ 
cords on request. A primary damage 
error signal is raised if the IDT 
cannot be loaded without error; the 
signal will force system termination 
as an error signal process model is 
not connected. 

Once an IDT has been successfully 
loaded, initialization progresses 
through a sequence of phases which 
correspond to the organization of da¬ 
ta within the IDT. An IDT consists 
of a maximum of nine sections of da¬ 
ta, preceeded by a header, and for 
each section there is an initializa- 
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tion phase whose responsibility is to 
convert the data in the section into 
system data and activity appropriate 
to the desired operational state. 
The sections and phases, which for 
convenience are referred to by the 
same names, are processed in the fol¬ 
lowing sequence. 

o System parameters. This section 
contains configuration descrip¬ 
tion block values [Figure 10.1], 
M-storage area reservation 

sizes, and general system data. 
The initialization phase for the 
section simply sets parameters 
to the given values. 

o Dispatching structure. This 
section contains R-process 
source dispatching priority val¬ 
ues, and the characteristics of 
each computation cycle in a de¬ 
scriptive form similar to a com¬ 
putation cycle status record 
[Figure 10.3], arranged in order 
of computation cycle precedence. 
The initialization phase for the 
section builds the dispatching 
structure corresponding to this 
data in the system data area. 

o Space Definition. This section 
contains entries which specify 
the length and content of module 
and data spaces which are re¬ 
quired to define process models, 
or which must be present in the 
system prior to initiation of the 
first regular process. Each en¬ 
try has a name by which it can be 
referenced from other sections 
of the IDT, and may also have an 
associated domain name. For each 
entry, the initialization phase 
for the section allocates a space 
of the given size, stores the da¬ 
ta into it, and assigns the space 
to the given domain, newly formed 
if necessary. 

o service process models. This 
section contains the data to com¬ 


plete those process models. Ref¬ 
erences to spaces are either in 
terms of a name for an entry in 
the space definition section of 
tiie IDT, or in terms of pointers 
to B-spaces which previously 
existed in the system. The in¬ 
itialization phase for the 
section is then able to define 
and connect the process models to 
their process sources. 

o R-procass models, D-process 
medals, C-process models. These 
sections contain entries which 
are process model definition 
blocks of the given class. As in 
the case of the service process 
models section, space references 
are either in terms of a name for 
an entry in the space definition 
section or are B-space pointers. 
The initialization phases for 
these sections define or connect 
the process models corresponding 
to the entries. 

o System checkpoint. This section, 
which is present only if the IDT 
was generated by a CHECKPOINT in¬ 
struction [Section 12.8], con¬ 
tains internal system data saved 
by the checkpoint; it is the only 
section of an IDT whose data foi— 
mat is model-dependent. The 
initialization phase for the 
section restores the information 
to the system data area. It may 
also allocate M-spaces by LOAD 
instructions applied to B-spaces 
containing data saved during the 
checkpoint, and set up state vec¬ 
tors for processes whose activ¬ 
ity is to restart from the point 
of suspension. 

o Application initialization. This 
section contains data whose 
structure and content is not 
known to initialization. The da¬ 
ta may have been created at any 
time, and in any manner, and at¬ 
tached to the IDT when it was 
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stored on the initialization de¬ 
vice. The section also contains 
the name of an input queue asso¬ 
ciated with some C-process mod¬ 
el. The initialization phase for 
the section completes the in¬ 
itialization procedure, and as 
the final step allocates an 
M-space, places the section data 
into it, enqueues the space on 
the given queue, and releases the 
system to normal operation. If 
the process initiated as a result 
of the enqueue is dispatched in 
the first computation cycle, it 
will be able to use the data to 
set up starting conditions for an 
application or operating system. 

The header of an IDT is the only part 
which is required to be present. If 
a data section is missing, the 
initialization phase for the section 
will substitute default values for 
data which is essential to system op¬ 
eration, and will omit all activity 
related to non-essential data. The 
default values, which are the same 
for all systems, need not be the val¬ 
ues in the IDT installed in the 
B-storage initialization area. If an 
error or inconsistency is noted in 
the data of any section, initializa¬ 
tion will proceed as if the section 
were missing. A warning report will 
then be generated when the initial¬ 
ization procedure is completed. 

1 2.2 Initialization Data Table 

In order to simplify the task of con¬ 
structing an IDT, data sections are 
treated as independent, self-con¬ 
tained units, and may appear in any 
order. The first byte of each 
section is an identifier whose value 
specifies the section content as : 

0 = system parameters 

1 = dispatching structure 

2 = space definition 

3 = service process models 

4 = R-process models 


5 = D-process models 

6 = C-process models 

7 = system checkpoint 

8 = application initialization 

If a section is of variable length, 
the three bytes which follow the 
identifier byte specify the length. 
Using the identifier and length val¬ 
ues, initialization will search the 
table, if necessary, to locate a 
section required for a given phase. 
The structural ordering of an IDT is 
not entirely arbitrary, however, as 
the first item must be a header in 
the format described in figure 12.1. 
The SID and CtOK fields of the header 
are provided as information by the 
system checkpoint function. A valid 
IDT may be constructed with arbitrary 
values for these fields, as they are 
not examined or used in any way by 
initialization. 

After a system has once been put into 
productive operation, subsequent in¬ 
itializations may be carried out on 
the data base preserved in the system 
from a previous period of operation. 

o If field DBI of the header is ze¬ 
ro, previous data is to be ig¬ 
nored, and the space allocation 
list is set up as initially emp¬ 
ty. Consequently, space refer¬ 
ences in the IDT must all be in 
terms of entries in the space de¬ 
finition section, as there are no 
pointers initially valid. 

o If field DBI is non-zero, the 
B-spaces, B-space pointers, and 
B-space allocation list present 
in the system from the previous 
period of operation form the data 
base for initialization. The al¬ 
location list is set up by fetch¬ 
ing the B-space list resident in 
B-storage and setting the 
M-space list empty, as M-spaces 
cannot be preserved. Space ref¬ 
erences in the IDT may be entries 
in the space definition section 
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DBI 


IDTL 


SID 


CLOK 


Figure 12.1 

Initialisation Data Table Header 


Field 

Offset 

Bytes 

Description and Use 

DBI 

0 

1 

Describes the initial data base. If the field is ze¬ 
ro, any data resident in the system is to be ignored. 
If the field is non-zero, resident B-space data is to 
be accepted as current. 

IDTL 

1 

3 

Combined length in bytes of the header and all data 
sections in the IDT. 

SID 

4 

4 

Identifier of the system. 

CLOK 

8 

8 

Time in system clock form when the IDT was con¬ 
structed or generated. 


SECT Res 

STAT ERSM 

RPA 

DP A 

CPA 

QHA 

CTRA 

PROL 


Figure 12.2 

Initialization Data Table 
System Parameters Section 


Field Offset Bytes 


Description and Use 


SECT 0 1 


Contains the value zero, indicating this is the sys¬ 
tem parameters section of the IDT. 


STAT 2 1 


Initial value for the statistics collection mask. 


ERSM 3 


1 Initial value for the error signal mask. 
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RPA 4 2 

DPA 6 2 

CPA 8 2 

QHA 10 2 


Count of the number of R-process sources for which 
process model and state vector space should be re¬ 
served in M-storage. 

Count of the number of I/O devices for which process 
model and state vector space should be reserved in 
M-storage. 

Number of bytes of M-storage to be reserved for 
C-process models. 

Number of bytes of M-storage to be reserved for queue 
header data and C-process model state vectors. 


CTRA 12 2 


Number of bytes of M-storage to be reserved for sta¬ 
tistical counters. 


PROL 12 2 Value to be used for the promotion limit for gates 

held by R-processes [Section 6.53. The nominal limit 
will be used if the field is zero. 



Figure 12.3 

Initialization Data Table 
Dispatching Structure Section 


Field Offset Bvtes 
SECT 0 1 

SLEN 1 3 

CCNO 4 1 

OCID 5 1 


Description and Use 

Contains the value 1> indicating this is the computa¬ 
tion cycle structure section of the IDT. 

Total length of the section in bytes. 

Number of computation cycles to be installed on the 
system. 

Overrun cycle indicator. 


x "x, 
l 

'A 
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PSCT 

6 

2 

Number of process source identifiers contained in 
field PSENT. 

BCT 

8 

8 

Time in system clock format which is to be used for 
the basic cycle. 

CCENT 

16 

Var 

Entries specifying the computation cycle character— 
isties, arranged in order of cycle precedence. The 
number of entries is equal to the value of field CCNO. 

PSENT 

Var 

Var 

Process source identifiers, ordered by relative dis¬ 
patching priority. 


or B-space pointers which iden¬ 
tify an existing space. 

Although an IDT with data base indi¬ 
cator field non-zero is the simplest 
way of providing continuity from one 
period of operation to the next, a 
zero-indicator field IDT can also be 
used if the space definition section 
contains entries for all spaces to be 
preserved. Such an IDT is required, 
in fact, if the system is to be re¬ 
stored to an operational state not 
consistent with the state at termi¬ 
nation of the previous period, as is 
the case for a full checkpoint 
[Section 12.8] . 

12,3 System Parameters 

The system parameters data section of 
an IDT is fixed in length, with the 
format described in figure 12.2. 

In addition to setup of the parameter 
values from fields STAT, ERSM, and 
PROL, the system parameters initial¬ 
ization phase structures the system 
data area to reflect the space 
requests, if feasible. If the space 
requests are judged excessive for the 
amount of M-storage installed on the 
system, they are reduced proportion¬ 
ately to satisfactory values; the 
amount of reduction is model-depen¬ 


dent. If the section is not present 
in the IDT, the phase substitutes 
zeros for all field values. 

12.4 Dispatching structure 

The dispatching structure section of 
an IDT is of variable length, with 
the format describe in figure 12.3. 

The dispatching structure initial¬ 
ization phase forms the initial dis¬ 
patching tables in the system data 
area. If field PSCT is zero, or if 
the section is not present in the 
IDT, the phase assigns factory- 
installed values as the dispatching 
priorities of the R-process sources. 
If the field is not zero, new dis¬ 
patching priorities are assigned to 
all sources, starting with the 
sources whose identifiers are con¬ 
tained in field PSEHT. The relative 
priorities are assigned in the order 
the sources appear, with the first 
source receiving the highest priori¬ 
ty. Priorities are then assigned to 
the sources not specified by select¬ 
ing them in the order of their fac¬ 
tory-installed priorities. 

Each entry in the computation cycle 
portion of the section, field CCENT, 
is a double-word with the format de¬ 
scribed in figure 12.4. 
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CCID 

CCPER 

SRT 

OSC 

SRD 


Figure 12.4 

Initialization Data Table 
Computation Cycle Entry 


Field 

Offset 

Bvtes 

Description and Use 

CCID 

0 

1 

Identifier of the computation cycle corresponding to 
the entry. 

CCPER 

1 

3 

Period of the computation cycle. 

SRT 

4 

1 

Type number of the selection routine for the cycle. 

OSC 

5 

1 

Overrun sequence count for the cycle. 

SRD 

6 

2 

Reserved for use as selection routine input data. 


In addition to formation of the 
specified computation cycle struc¬ 
ture in the system data area, the 
initialization phase constructs a 
special time event request block for 
the basic cycle. This TERB will be 
inserted into the time event queue in 
the final phase of initialization, 
and will remain in the queue effec¬ 
tively at all times, as the microcode 
process invoked by the event will re¬ 
quest reinsertion of the updated 
TERB . 

If the section is not present in the 
IDT, the phase will assume the system 
is to operate with a single computa¬ 
tion cycle of indefinite period gov¬ 
erned by the infinite sequential 
selection routine [Section 4.41. The 
identifier of the cycle is set to ze¬ 
ro. The overrun cycle indicator and 
overrun sequence count are also set 
to zero, but their values have no 
effect on system operation as an 
overrun cannot occur. The basic cy¬ 
cle time is set to 1.048576 seconds. 


obtained by inserting a 1 into bit 
position 31 of the 64-bit clock 
field. 

12.5 Space Definition 

The space definition section of an 
IDT is variable length, with the for¬ 
mat described in figure 12.5. The 
space definition entries in field 
SDENT of the section are themselves 
variable in length, with the format 
described in figure 12.6. 

The space definition initialization 
phase constructs a table of 
name-pointer pairs, one pair for each 
entry in the section, which is ac¬ 
cessed by the remaining initializa¬ 
tion phases whenever a pointer is 
required for a space referred to by 
name. An empty table is constructed 
if the section is not present in the 
IDT. When the section is present, 
space definition is carried out in 
the following way. 
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Field 

SECT 

SLEN 

SDENT 


Fi eld 
DISP 


SECT 

SLEN 

SDENT 


Figure 12.5 

Initialization Data Table 
Space Definition Section 


Offset Bytes 


Description and Use 


0 1 


Contains the value 2, indicating this is the space 
definition section of the IDT. 


1 3 Total length of the section in bytes. 

4 Var Entries specifying the spaces which are to be de- 

f i ned. 



Figure 12.6 

Initialization Data Table 
Space Definition Entry 


Offset Bytes 


Description and Use 


0 1 


Bits which describe the initial disposition of the 
space. 


Bit Value 


5ignificance 


0 


0 

1 


The space is to be an ordinary space 
The space is to be a module space 


1 


0 The space is to remain an M-space 

1 The space is to be converted to a B-space 
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2 0 

1 

3 0 
1 

4 0 
1 

5 0 
1 

6 0 
1 

7 

Field Offset Bytes 

SPSZ 1 3 

SPNME 4 4 

DOMNM 8 4 

DTSZ 13 3 

DT A 16 Var 


Assign the space to the common domain 

Assign the space to the domain whose name is in field 
DOMNM 

Space custody may be transferred 

The space is to be bound to system custody 

Read access is to be family 

Read access is to be domain or public 

Write access is to be family 

Write access is to be domain or public 

Normal 

The space pointer is required to be a pointer from a 
previous operational period 

Reserved 


Description and Use 


Number of bytes to be allocated for the space. 

Name by which the space can be referenced within any 
initialization phase. 

Name of a domain to which the space is to be assigned. 
The significance of this field is controlled by bit 2 
of field DISP. 

Number of bytes of data in field DTA. 

Data to be stored into the space. 


o An M-space is allocated equal in 
size to the value of field SPSZ 
of the entry, and the data from 
field DTA is placed into it. The 
type of space allocated is con¬ 
trolled by bit zero of field 
DISP. The space is in system 
custody, with family (i.e. sys- o 
tem) read and write access. 

o If bit 2 of field DISP is 1, the 
equivalent of an ASSIGN instruc¬ 
tion referencing the name in 
field DOMNM is applied to the 
space, causing a domain of that 
name to be formed if one did not 
previously exist. If the domain o 

188 


already exists, the space is sim¬ 
ply assigned to it, and the mem¬ 
bership count increased by 1. If 
bit 2 of field DISP is zero, the 
space remains in the common do¬ 
main. 

If an access bit of field DISP is 
1, and if the space was assigned 
to a domain other than the common 
domain, the corresponding access 
type is set to domain; if the 
space was assigned to the common 
domain, the access type is set to 
public. 

If bit 1 of field DISP is 1, a 
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B-space is allocated by the 
equivalent of a SAVE instruction 
applied to the space. The ori¬ 
ginal space is deleted from the 
system whan the save is success¬ 
fully completed, and the B-space 
pointer replaces the M-space 
pointer in the name-pointer ta¬ 
ble. 

o The space is either bound to sys¬ 
tem custody or left unbound, as 
determined by the value of bit 3 
of field DISP. If it is not 
bound, it may be bound to custody 
of some process model during a 
subsequent phase of initialisa¬ 
tion. If so, any access type of 
family refers to the new custo¬ 
dian. 

If the IDT was generated by a check¬ 
point, the reference name in field 
SPNME of an entry is actually the 
pointer assigned to the space at that 
time, and bit 6 of field DISP is set 
to 1 for all M-space entries, and for 
all B-space entries whose pointers 
must be restored to their previous 
values. For those entries, the space 
definition phase supplies the space 
allocator with the entry name, and if 
it is consistent with a pointer for 
the type of space requested, the 
allocator will assign the name as the 
pointer. A pointer substitution flag 
set by the phase will cause an allo¬ 
cation list consistency check to be 
carried out in the system checkpoint 
phase [Section 12.8]. 

12.6 Service Process Models 

The service process models data 
section of an IDT is fixed length, 
with the format described in figure 
12.7. The service process models in¬ 
itialization phase defines or con¬ 
nects the process models whose data 
is contained in the section. The 
R-process source dispatching priori¬ 
ties are set to their final values by 
assigning the specified priorities 


to the sources of the section, with 
the error signal source always having 
the highest priority. The other 
sources in the system are reduced in 
priority to accommodate insertion of 
the section source priorities if nec¬ 
essary. If the section is not pre¬ 
sent in the IDT 

o the null space is used for all 
instruction module and entry 
context spaces 

o the statistics collection and 
domain exception process models 
are assigned to the computation 
cycle of lowest precedence 

o the clock is assigned dispatch¬ 
ing priority just below that of 
the error signal process source 

o the other R-process sources of 
the section are assigned the low¬ 
est dispatching priorities, in 
the order they appear in the 
section. 

Space identifiers in the section must 
always be references to entries in 
the space definition section when 
field DBI of the header is zero [Fig¬ 
ure 12.1]. If the IDT was generated 
internally, references to existing 
B-spaces, rather than space defi¬ 
nition section references may be sup¬ 
plied, and field SINT provides the 
means for the phase to determine the 
type of reference supplied. 

In either case, if a B-space is the 
referent for an entry context space 
or instruction module of an R-process 
model, the i nitialization phase ob¬ 
tains a descendent M-space for use in 
connecting the model by the equiv¬ 
alent of a LOAD instruction. The oi— 
iginal B-space is then deleted from 
the system if its control bit in 
field SDIS is set to 1. If a B-space 
which appears in the name-pointer 
pair table is deleted, the B-space 
pointer in the table is replaced by 
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Field 

SECT 

SCCC 

DOCC 

SDIS 


SECT 

SCCC 

DOCC 

SDIS 

PRCLK 

PRIPM 

PRFSX 

SINT 


TECTX 


OVSPR 


SCSPR 


DOSPR 


IVSPR 


FXSPR 


ERSPR 


Figure 12.7 

Initialization Data Table 
Service Process Models Section 


Offset Bytes 


Description and Use 


0 1 Contains the value 3, indicating this is the service 

process models section of the IDT. 

1 1 Identifier of the computation cycle for the statis¬ 

tics collection process model. 


2 1 Identifier of the computation cycle for the domain 

exception process model. 


3 1 Bits which control the disposition of B-spaces used 

as antecedents of instruction module or entry context 
spaces for R-process models. A B-space is deleted 
from the system if its disposition control bit is set 
to l: 


Bit 


Controls 


0 


Not used 


1 


Entry context space of the time event process model 


2 

3 


Instruction module space of invalid process model ex¬ 
ception process model 
Entry context space for that model 


v. 
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4 

5 


Instruction module space of forced system exception 
process model 

Entry context space for that model 


6 

7 


Instruction module space for error signal process 
model 

Entry context space for that model 


Field Offset Bytes Description and Use 

PRCLK 4 2 Dispatching priority of the system clock as an R-pro- 

cess source. 


PRIPM 6 2 

PRFSX 8 2 

SINT 10 2 


TECTX 12 4 

OVSPR 16 8 

SCSPR 20 8 

DOSPR 32 8 

IVSPR 40 8 

FXSPR 48 8 

ERSPR 56 8 


Dispatching priority of the invalid process model ex¬ 
ception process source. 

Dispatching priority of the forced system exception 
process source. 

Significant only if the IDT was generated by a check¬ 
point, in which case the first thirteen bits of the 
field define the interpretation of the space identi¬ 
fiers in the remaining thirteen fields of the 
section. Correspondence between bit and field is ob¬ 
tained by taking the bits from left to right and the 
space fields from top to bottom; the rightmost three 
bits are not used. If a bit is zeroi the correspond¬ 
ing space identifier is the name of an entry in the 
space definition section of the IDT. If a bit is 1, 
the space identifier is a B-space pointer. 

Identifer of the entry context space for the time 
event process model. 

Identifiers of the pair of spaces required to define 
the overrun process model. The first four bytes 
identify the instruction module space, the last four 
the entry context space. 

Identifiers of the pair of spaces required to define 
the statistics collection process model. 

Identifiers of the pair of spaces required to define 
the domain exception process model. 

Identifiers of the pair of spaces required to connect 
the invalid process model exception process model. 

Identifiers of the pair of spaces required to connect 
the forced system exception process model. 

Identifiers of the pair of spaces required to connect 
the error signal process model. 
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Fi eld 
SECT 

SLEN 

PMENT 


Field 

SDIS 


SECT 

SLEN 

PMENT 


Figure 12.8 

Initialisation Data Table 
Regular Process Models Sections 


Offset Bvtes 


Description and Use 


0 1 


Contains the value of the identifier which indicates 
the section type. 


1 3 


Total length of the section in bytes. 


4 Var Entries which specify process models to be defined or 

connected. 


SDIS 

SINT 

IDR 

PMDB 


Figure 12.9 

Initialization Data Table 
Regular Process Model Entry 


Offset Bvtes Description and Use 

0 1 Bits which control the disposition of B-spaces used 

as antecedents of M-spaces required for field PMDB of 
the entry. A B-space is deleted from the system if 
its disposition control bit is set to 1= 

B i t Controls 

0 Instruction module space 

1 Exception module space 

2 Entry context space 

3-7 Not used 
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Field Offset 

Bvtes 

Description and Use 

SINT 1 

1 

Significant only if the IDT was generated by a check¬ 
point, in which case the bits define the interpreta¬ 
tion of space identifiers in field PMDB of the entry. 
If a bit is zero, the corresponding space identifier 
is the name of an entry in the space definition 
section of the IDT; if a bit is 1, the space identifi¬ 
er is a B-space pointer. Bit and identifier corre¬ 
spondence is the same as that of field SDIS. 

IDR 2 

2 

Identifier of an R-process source or I/O device to 
which the process model is to be connected. The field 
has no'si gni ficance for a C-process model. 

PflDB 4 

Var 

The RMDB, DMDB, or CMDB which is to be connected or 
defined. 


the M-space pointer to its 
descendant. 

12.7 Regular Process Models 

The R-process models, D-process mod¬ 
els, and C-process models sections of 
an IDT are variable in length, with 
the section format described in fig¬ 
ure 12.8. PMENT field entries in 
each of the three sections have the 
same basic format, as described in 
figure 12.9. 

If a section is not present in the 
IDT, the corresponding process mod¬ 
els initialization phase proceeds 
directly to the next phase of in¬ 
itialization. When a section is pre¬ 
sent the phase connects or defines 
all process models whose definition 
blocks are contained in the xection. 
Space identfiers in a block must al¬ 
ways be references to entries in the 
space definition section when field 
DBI of the header is zero. If field 
DBI is non-zero, field SINT provides 
the means for the phase to determine 
whether the reference is to a space 
definition entry or is a pointer to 
an existing B-space. Field SDIS of 
each entry determines the disposi¬ 
tion of any such B-space, in the same 


way as does its namesake field in the 
service process models section. 

12.8 System checkpoint 

A system checkpoint generates an IDT 
whose content allows system opei— 
ation to restart with conditions re¬ 
stored to those in effect at the time 
of the checkpoint. As this requires 
system operation to be suspended dui— 
ing generation of the IDT, and may 
require substantial output, the ef¬ 
fectiveness of the CHECKPOINT 
instruction (CHECK) is controlled by 
bit 6 of the error signal mask 
[Section 11.4]. If the bit is zero, 
the instruction is effective only 
when executed within an error signal 
process; nothing happens if it is ex¬ 
ecuted within an R-process of any 
other family except to return a con¬ 
dition code indicating that check¬ 
point is inhibited. If the bit is 1, 
CHECK is effective within any R-pro¬ 
cess. 

When CHECK is effective, a signal is 
transmitted to all CPU and PPU re¬ 
questing suspension of operation. 
The signal will inhibit pending con¬ 
ditions for process sources from be¬ 
coming effective, and will cause 
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those CPU not interpreting the CHECK 
instruction to cease activity at the 
completion of the next microinstruc¬ 
tion sequence which preserves integ¬ 
rity of the local data. PPU 
instruction interpretation activity 
will also cease at the first opportu¬ 
nity, but microcode activity will 
continue, if necessary, until com¬ 
pletion of all I/O operation 
sequences started prior to the recep¬ 
tion of the signal. Consequently, 
all internal activity will eventual¬ 
ly stop, leaving the system in some 
consistent operational state. The 
CPU interpreting the 'CHECK instruc¬ 
tion will then generate an IDT corre¬ 
sponding either to a full checkpoint 
or a partial checkpoint, depending on 
the option selected for the instruc¬ 
tion. 

o A full checkpoint dumps all 
M-space and B-space data in the 
system into the space definition 
section, with the entries set to 
restore pointers [Section 12.51. 

o A partial checkpoint dumps only 
the B-space data; the entries can 
be set either to restore pointers 
or not, as specified by a second 
option of the instruction. 

The identifier of the output device 
for the checkpoint IDT is specified 
by an operand of the CHECK instruc¬ 
tion. If the device is a real de¬ 
vice, the space definition section of 
the IDT will contain the appropriate 
data, and field DBI of the header is 
set to zero. If the device is the 
null device, the instruction will be 
rejected unless a partial checkpoint 
is specified. In that case, an IDT 
without a space definition section, 
but with a non-zero DBI field, will 
be placed into the initialization 
area of B-storage. 

Apart from the space definition 
section and the header, the compos¬ 
ition of a checkpoint IDT is model- 


dependent. For some EPSILON systems, 
the complete system data area is 
copied into the system checkpoint 
section, eliminating any requirement 
for for the system parameters, dis¬ 
patching structure, service process 
models, and regular process models 
data sections. Other systems reduce 
the amount of data in the system 
checkpoint section by output of the 
other sections. In all cases, howev¬ 
er, the system checkpoint section 
contains the state vectors of all 
processes in the system, and the 
space allocation list in effect at 
the time of the checkpoint. 

The system checkpoint initialization 
phase replaces data in the system da¬ 
ta area by any corresponding data in 
the system checkpoint section. Con¬ 
sistency checks to assure that no 
conflict arises from the substi¬ 
tution are applied at each stage, and 
failure at any stage will force sys¬ 
tem termination. 

o The space allocation list in the 
section is compared with the ex¬ 
isting space allocation list. If 
any pointers from previous peri¬ 
ods were used in the space defi¬ 
nition phase [Section 12.51 the 
section list must be an exact 
subset of the existing list; if 
not, a consistency failure has 
occurred. If previous pointers 
were not used, or if there is no 
inconsistency, the custody, ac¬ 
cess, and domain data for each 
spce in the name-pointer pair 
list is transferred from the 
section allocation list to the 
existing list. Spaces and do¬ 
mains in existence at the time of 
the checkpoint are therefore re¬ 
stored to their original state. 

o If the section contains system 
parameter, dispatching struc¬ 
ture, R-process model, or D-pro- 
cess model data, the section data 
replaces its counterpart in the 
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system data area. 

o The state vector data in the 
section is then matched against 
the dispatching data in the sys¬ 
tem data area. A consistency 
failure occurs if there is a pro¬ 
cess state vector corresponding 
to a process modal not assigned 
to a computation cycle or con¬ 
nected to a source, or if the 
state vector data conflicts with 
the family data. If there is no 
failure, the state vector data is 
transferred to the system data 
area . 

o If the section contains C-pro- 
cess model data, it must match 
the existing C-process model da¬ 
ta wherever the process model 
names are the same; a consisten¬ 
cy failure is recorded if there 
is a mismatch for some model. If 
there is no failure, the data for 
those process models of the 
section not already in the exist¬ 


ing C-process model list is 
transferred to that list, and to 
the system data area where appro¬ 
priate. 

After completion of the system check¬ 
point phase, the internal state of 
the system is either the same as it 
was at the time of the checkpoint, or 
contains the checkpoint state as a 
proper subset. However, neither ap¬ 
plication data, data on I/O devices 
with removable media, nor devices for 
which positioning is significant, 
need be in the state they were at 
checkpoint. If the system must be 
restored to full checkpoint condi¬ 
tion, the final steps can only be ac¬ 
complished by application 
initialization. 

12,9 Application Initialization 

The application initialization data 
section of an IDT is variable length, 
with the format described in figure 
12 . 10 . 



Figure 12.10 

Initialization Data Table 
Application Initialization Section 


Field Offset Bytes 


Description and Use 


SECT 0 1 


Contains the value 8, indicating this is the applica¬ 
tion initialization section of the IDT. 


SLEN 1 

SQUE 4 


3 Total length of the section in bytes. 

4 Name of an input queue which is to receive the section 
data. 
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SDAT 8 Var Data to be supplied to the queue for initialization 

of an application or operating system. 


Whether the section is present in the 
IDT or not, the application initial¬ 
ization phase always completes the 
initialization procedure. 

o If there was no system checkpoint 
section in the IDT, an IDT with 
non-zero DBI field in the header 
is generated and placed into the 
B-storage initialization area. 
This IDT, which is the same as 
would be generated by a partial 
checkpoint, provides a means for 
restarting the next operational 
period with operating condition 
identical to the period just be¬ 
ing started. 

o If an application initialization 

section is present, the equiv¬ 
alent of a QIX instruction 
applied to the SQUE field is exe¬ 
cuted. If a queue index is re¬ 
turned, an M-space is allocated 
to hold the data in field SDAT, 
and the space is placed into the 
queue. A warning report will be 
generated if there is no queue 
with the specified name. 

o Statistical counters are as¬ 

signed for system data, R-pro- 
cess sources, and I/O devices if 
counter assignment is not sup¬ 
pressed [Section 10.4]. 

o The system clock is synchronized 

with external real time by set¬ 
ting its value to the difference 
between current time and the 
standard epoch. The time of day 
is supplied either by the system 
operator or by an external timing 
signal. A basic cycle TERB is 
generated and inserted into the 


timing queue. 

o The time of initialization is re¬ 
corded, sequence numbers are re¬ 
set, and process source 
inhibition removed. The system 
is then free to operate normally. 

o A warning report is generated if 
any inconsistency or error was 
noted during initialization 
which was not cause for system 
termination. 

An application initialization data 
section can be output as part of a 
checkpoint IDT by selecting that 
option of the CHECK instruction. The 
data for the SQUE and SDAT fields 
must have been previously generated 
and placed into an M-space, in the 
order required for the section. The 
fields are located by the second op¬ 
erand of the instruction, and the 
SDAT field is assumed to extend from 
its first byte to the last byte of 
the M-sapace. 

12.10 System Termination 

System termination is invoked by a 
DIAGNOSE instruction, or from the op¬ 
erator console by depressing the tei— 
mination key. Termination triggers 
the signal which causes the system 
12.81. When activity has ceased, the 
CPU processing the termination 
signal will update the space allo¬ 
cation list in B-storage. This will 
assure that the IDT in the B-storage 
initialization area will be consist¬ 
ent with a restart from the point of 
termination. The system will then be 
reset to the initial operational 
state. 
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12.11 instruction Descriptions 
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CHECK R1,M3,D2(B2) <RS> 

The instruction is terminated with condition code 3 if arithmetic register 
R1 does not contain the identifier of an I/O device, or the identifier of the 
null device. It is terminated with condition code 2 if the process executing 
the instruction is not an error signal process and bit 6 of the error signal 
mask is zero. If arithmetic register R1 contains the identifier of the null 
device, bit zero of mask field M3 must be 1 (partial checkpoint), bit 1 of the 
field must be zero (pointers to be restored), and bit 2 must be zero (no appli¬ 
cation initialization section). The instruction is terminated with condition 
code 3 if any of these bit conditions is not met. If bit 2 of field M3 is 1, 
the instruction is suppressed with a specification exception if the second op¬ 
erand does not define a location on a word boundary. 

If the instruction is not terminated or suppressed, a signal is broadcast 
to all CPU and PPU requesting cessation of activity. The CPU interpreting the 
instruction then idles until all cessation bits are recorded in the system da¬ 
ta area, or until a basic cycle has expired. If a basic cycle expires before 
cessation of activity has been completed the signal is broadcast again. If 
the signal is trnasmitted 256 times in succession without activity having 
ceased or a delay request having been received from a PPU, the cessation re¬ 
quest is cancelled and the instruction is terminated with condition code 1. A 
delay request by a PPU will cause the signal trnasmission sequence count to be 
reset to 1. 

When cessation of activity has been completed, the total length required 
for the IDT is computed. The length computation takes into account the type 
of IDT to be generated and the conventions employed for output of system 
checkpoint data by the model of EPSILON system within which the instruction is 
being executed. A full checkpoint (bit zero of field M3 set to zero) genei— 
ates a space definition section containing data for all M-spaces and B-spaces 
in the system. A partial checkpoint on a non-null device generates a space 
definition section containing data for all B-spaces in the system. If bit 2 
of field M3 is 1, an application initialization section is to be output. The 
section content, which is located by the second operand, extends to the end of 
the space in which it is located. A request is made for an M-space to contain 
the header and the system checkpoint data section. The instruction is termi¬ 
nated with condition code 1 if space is not available. 

The header and system checkpoint data section are assembled and placed in¬ 
to the space allocated, for output as a single record. If the output device is 
null, the record is placed into the initialization area of 8-storage. If the 
device is non-null, an I/O request is placed into its request queue, and a PPU 
through which the device is attached to the system is signalled to become ac¬ 
tive. Execution of the instruction is suspended until completion of the I/O 
request. !tf The remaining data sections of the IDT are assembled, if assembly 
is required, and output in sequence, each section consisting of one or more 
physical records. When all sections have been output, a signal is broadcast 
to all CPU and PPU requesting resumption of activity. The instruction is then 
terminated with condition code 1 if any error occurred during output of the 
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IDT, and with condtion code zero if no error was detected. 

Process Class: R 

Condition Code : 

0 IDT output successful 

1 IDT could not be output 

2 Checkpoint inhibited 

3 Device not available 

Exceptions : 

Specification 
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